Agile Release Planning | Mike Cohn's Blog

Posts Tagged ‘agile release planning’

Balancing Anticipation and Adaptation

Thursday, November 5th, 2009

A big part of an organization’s becoming agile is finding the appropriate balance between anticipation and adaptation, as Jim Highsmith wrote in Agile Software Development Ecosystems. The following figure shows this balance along with activities and artifacts that influence the balance.

Balancing anticipation with adaptation.

When doing up-front analysis or design, we are attempting to anticipate users’ needs. Because we cannot perfectly anticipate these, we will make some mistakes; some work will need to be redone. When we forgo analysis and design and jump immediately into coding and testing with no forethought at all, we are trying to adapt to users’ needs.

All projects of interest will be positioned somewhere between anticipation and adaptation based on their own unique characteristics; no application will be all the way to either extreme. A life-critical, medical safety application may be far to the anticipation side. A three-person startup company building a website of information on kayak racing may be far toward the side of adaptation.

Foretelling the agile preference for simplicity, in 1990, was speaker and author Do-While Jones.

I’m not against planning for the future. Some thought should be given to future expansion of capability. But when the entire design process gets bogged down in an attempt to satisfy future requirements that may never materialize, then it is time to stop and see if there isn’t a simpler way to solve the immediate problem.

Agile teams avoid this “bogging down” by realizing that not all future needs are worth worrying about today. Many future needs may be best handled by planning to adapt as they arise.

For more information on this topic, see Succeeding with Agile: Software Development using Scrum.

Posted in Agile Planning | 5 Comments »

Using a One-Handed Clock to Convey Project Goals

Tuesday, October 6th, 2009

The “iron triangle” is a long-accepted way of talking about the four parameters of project success. In the iron triangle, scope, schedule and budget each takes its place along a side of the triangle. Quality is placed in the middle under the premise that we don’t mess with quality. We can, however, adjust the sides. Sometimes a product owner or key stakeholder is told, “Pick any two but I can adjust the third” by the project manager, ScrumMaster or coach. Sometimes the customer is told, “you can only lock down one of the sides.”

I’ve recently decided there’s a better way to convey the points we’ve been trying to make with the iron triangle–we use The One-Handed Clock of Project Goals.

To use the one-handed clock, position Scope, Schedule and Budget where twelve o’clock, four o’clock, and eight o’clock would be on a clock. It doesn’t matter which is positioned where but I put them as shown in the figure. Quality is again assumable fixed and not needed on the clock.

The one-handed clock before its hand is added.

Next, ask the product owner or key stakeholder to point the one hand where it best indicates the project’s goals. The one hand can be aimed, for example, directly at Schedule. This would indicate that Schedule is the most important goal and Scope and Budget both take a back seat to it.

A one-handed clock.

Or perhaps the one hand is pointed between Scope and Schedule showing a mix of importance between them.

1HandedClock-B

To see how the One-Handed Clock of Project Goals works, take a moment to think about it. You can position the hand anywhere between any two of three goals but one goal is always left out. In the terms of the iron triangle, that would be the side left flexible.

There are a lot of things I like about this new way of visualizing the relative importance of Scope, Schedule and Budget. I’ll mention two here:

The One-Handed Clock allows stakeholders or product owners to convey a position more precisely than saying something like “I pick Schedule and Budget.” The ability to point the arrow precisely rather than only directly at an item is essential.
The One-Handed Clock is a useful visual metaphor that can be hung in a team room. The iron triangle doesn’t really work for that as it’s hard to convey which sides were selected other than by darkening them, which doens’t show much.

Try this out and let me know what you think. The teams and product owners I’ve introduced it to so far have found it very helpful. I suspect you will as well. Also, let me know what else you use a one-handed clock for as it’s a useful visualization for any three competing factors.

Posted in Agile Planning | 36 Comments »

Two Chapters from Agile Estimating & Planning Avialable

Monday, September 21st, 2009

My publisher, Addison-Wesley, has just made two chapters from Agile Estimating & Planning available for free. Check out Chapter 1, The Purpose of Planning, and Chapter 3, An Agile Approach.

Posted in News | 22 Comments »

Why Do Release Planning?

Saturday, April 11th, 2009

I live in Colorado, which boasts some of the world’s best hiking trails and North America’s greatest concentration of mountain peaks over 14,000 feet (nearly 4,300 meters). There are so many mountains over 14,000 feet high here that they are referred to simply as “fourteeners.” Most of Colorado’s fourteeners are non-technical routes; no special equipment is needed and anyone in good shape can make it to the summit.

This means there are a couple of different ways to climb a fourteener. One approach is to drive to the base of the mountain and start walking toward the highest thing you see. This will almost certainly be a false peak—once you’re reached it, you’ll see a higher point that had been obscured by the false peak. So walk again toward the highest point you see. It, too, will probably be a false peak. But, keep this up long enough and you’ll eventually find the true summit. In doing so, though, you will probably have to descend into a few valleys only to climb higher on the other sides. The approach will feel highly inefficient.

A second way to climb a fourteener is to purchase a topographic map, identify a route up the mountain, and then proceed that way. Looking first at a topographic map allows you to plot a course to the summit that avoids much of the inefficiency of the first approach. Of course, we must be careful not to value our route plan too highly—a stream we plan to cross may be too deep when we get there or a rock slide may have made a trail impassable, and we’ll need to alter the route when we encounter these problems.

An agile team does release planning to avoid the same type of problems we avoid with a topographic map when hiking a fourteener. A release plan helps a team avoid finishing a series of sprints and feeling that, while they always worked on the highest priority items, the collection of work completed does not add up to a satisfying whole.

Posted in Agile Planning | 6 Comments »

Why There Should Not Be a “Release Backlog”

Sunday, February 8th, 2009

I haven’t heard the term “release backlog” in many months, but it’s come up in three conversations over the past week. So, I want to share my thoughts on whether a team should have a Release Backlog in addition to the conventional Product and Sprint (or Iteration) Backlogs.

First, let’s clarify what people mean when they refer to a “release backlog.” A release backlog is a subset of the product backlog that is planned to be delivered in the coming release, typically a three- to six-month horizon. A release backlog would presumably contain the same type of items as on a product backlog. My preference for this, of course, would be user stories. So, at the start of some release planning horizon, a product owner with help from the team and other stakeholders would example the product backlog, select some amount of high priority work and move those items to the release backlog. Later, in sprint (iteration) planning, the team would examine the release product and select some amount of work to do. (Notice how this already goes against existing agile literature that says the team selects top priority items for the sprint from the product backlog?)

I am opposed to the use of a release backlog for a couple of reasons:

First, in all projects that are not being done as fixed-scope contracts (and, arguably, even then) we don’t know exactly what user stories or features will be delivered in a release. To say that there is a release backlog may not imply a guarantee that all features on it are delivered. However, it does create additional work as items are moved off back and forth between the product and release backlogs. This will happen as the team’s velocity changes (even by small amounts) from sprint to sprint. If the release backlog is to show what a team will deliver in a release, it should contain an amount of work equal to the number of story points (or ideal days) times the number of remaining sprints. If you have an average velocity of 20 and 6 sprints left, the release backlog should contain 120 points worth of work. Suppose the team finishes 24 points of work in a sprint. The backlog is now down to 96 points (120-24) but should contain 100 (5 sprints left x an average velocity of 20). Things get even more difficult if that good velocity of 24 increases the team’s average velocity to 21. In that case the release backlog should contain 5×21=105 points of work; we need to move 9 points of work from the product backlog to the sprint backlog. If there’s a release backlog, this moving of items back and forth from product backlog to release backlog will happen every sprint.

Second, introducing a release backlog creates additional confusion. We’ve already overloaded the word “backlog” with “product backlog” and “sprint backlog.” Why confuse things further with a third type of backlog unless there is an immensely compelling reason to do so?

Third, introducing the concept of a Release Backlog actually makes it harder for product owners to do one of the most important things they should be doing–looking at the features or user stories that just miss the cut of being in a release. When I look at a product backlog and count down the number of story points that I anticipate will be in the release, the most interesting thing to me is not necessarily the set of user stories that will make it into the release. I’m often just as interested in the next few user stories below that cut-off point. That is, I want to know what user stories won’t quite make it into the release. After all, we say that one of the benefits of agile (on some, not all, projects) is the ability to decide later if we should release a few sprints early (if a lot has been done), on the planned date, or perhaps a sprint or two late if we want to add more functionality before a release. This is made more difficult with a Release Backlog because a product owner now needs to examine both a Product Backlog and a Release Backlog to make these decisions.

So, what do I propose instead?

I advocate that all teams track their velocities. This leads to a graph like this:

Velocity as graphed over the last nine sprints.

This graph shows a team calculating three average velocities:

Long term average, defined as the mean of the last eight sprints
Worst case average, defined as the mean of the worst three chosen among the last eight sprints
Best case average, defined as the mean of the best three chosen among the last eight sprints

You can choose your own ways of calculating long-term, best-case, and worst-case average velocities. These are just the ones I like. We use these average velocities as shown in this figure:

Using velocity to predict how much will be done by a given date.

In this figure, the product backlog is shown on the left as a stack of index cards. We use the three average velocities multiplied by the number of remaining sprints to draw arrows pointing into the product backlog. The range created by these arrows indicates the likely amount of work finished by the planned date. Our release plan is the work defined by the arrows. Rather than a Release Backlog as a new work product or artifact, my equivalent of a release backlog is the product backlog and these arrows pointing into it.

As you can imagine, predicting velocity as a range is much more likely to be accurate than using a single point estimate (“Our velocity is 31.”) as has been implied by everyone I’ve heard talk about a Release Backlog. Additionally, looking at figures like these should make it apparent that the amount of work expected to be delivered in a release will change from sprint to sprint. Pointing arrows into a product backlog is much easier and more helpful than creating a new work product, the Release Backlog.

Posted in Agile Planning, Sprint Artifacts | 48 Comments »

Interviewed by Software Process and Measurement Cast

Monday, October 6th, 2008

I was interviewed recently by Tom Cagley for the Software Process and Measurement Cast. Part 1 of the interview is available for download now. During the interview, Tom and I discuss agile estimating and planning. Part 2 will be available in early November.

Posted in News | No Comments »

Predicting Velocity When Team Membership Or Size Changes Frequently

Monday, August 11th, 2008

As a measure of the amount of work completed in an iteration, velocity works extremely well when teams are relatively stable. If the same people stay on a team, it is reasonable to assume that the amount of work they complete will be relatively constant from iteration to iteration. This allows us to plan using inferences such as “This team has an average velocity of 25 points per iteration over the last year and they have time for 8 iterations in this new project; therefore they will complete around 200 points in those 8 iterations.”

But what do we do when team membership or size changes frequently?

To answer this question most effectively, you should collect data on how teams of different sizes have performed over time in your organization. When I was a VP of Development at a couple of agile organizations, I used to collect data on velocity and team size changes in a simple spreadsheet similar to this:

Initial Team Size	New Team Size	Median of Last 5	Iteration +1	Iteration +2	Iteration +3
6	7	25	20	24	28
6	7	16	16	15	19
8	6	50	40	40	42
7	8	12	10

The first column represented the size of the team before a change occurred. The next column represented the new size of the team (up or down). The third column was what I considered to be a reasonable “long term average” velocity for the team at its initial size. Because team’s could change frequently (by a person or two) I settled on using the median value of the team’s last five iterations. The tradeoff in using a longer measure (median of 15 iterations perhaps) is that you’d have fewer observations. The next columns represent the actual velocities of teams over the next three iterations. Notice that for the last team values are not shown for the last two iterations. This is usually because the team size changed again. If you have a significant number of teams, the rows in this type of spreadsheet will accumulate quite quickly.

In some of the organizations where I used this approach we did not have a standardized definition of story point (or we’re using ideal days, which were not as normalized as you might think). So all analysis was done on a percentage basis. What I wanted to know was “What is the average impact of adding a person to a seven-person team?” I would have loved the answer to be something like “Velocity goes up 15%.” Unfortunately, it wasn’t that straightforward because velocity often dipped for a couple of iterations before going up. By tracking data I found that usually by the third iteration a team had settled in on a new velocity, which is why my spreadsheet above only tracks through Iteration+3. By all means, track more and see what you find. (But keep in mind that the data will get sparse as team sizes will change again.)

Another tab in my spreadsheet, expressed all the data in percentage terms. The first two rows

Initial Team Size	New Team Size	Iteration +1	Iteration +2	Iteration +3
6	7	-20%	-4%	+12%
6	7	0%	-6%	+15%

(Example: Iteration +1 in the first row is -20% based on the team dropping its velocity from 25 to 20.)

I then simply averaged these percentages for each team size change to get results like:

Initial Team Size	New Team Size	% Change in Iteration +1	% Change in Iteration +2	% Change in Iteration +3
6	7	-10%	-5%	+15%

This allowed me to answer all sorts of questions, including:

What will this team’s velocity be if we add two people?
How soon could we get this project if we added a person to each team?
If I want all those projects done by the end of the year, how many people would we need to add?
What would be the impact of not approving the new employees in the budget?
What would be the impact of a 15% layoff?

There are of course many flaws with this approach. Adding Susan to the project is very different than “adding an unknown person” to the project. Still, if I have the data on averages across the board in our organization I can make assumptions about specifically adding Susan (if I want, there can be many more risks in doing this). Notice that the approach does not attempt to take into consideration who it was that was added or even what skillset the person had. You could collect such data if you wanted. As anal about collecting all sorts of data like this as I am when I have access to it, I knew though that collecting that type of data would have made this just hard enough that I wouldn’t have done it regularly.

I did collect a few other bits of data that I left out of the initial table (so as to have more horizontal room for the data of real interest). For example, I collected data such as iteration length and the name of the team’s ScrumMaster (the latter was in case I had questions a few weeks later).

The approach described here was just simple enough that I could get empirical evidence of the impact of team size changes. This was invaluable when discussing headcount changes with product owners and the CEO.

Posted in Agile Planning | 12 Comments »

Visualizing a Large Product Backlog With a Treemap

Wednesday, July 2nd, 2008

In the early days we promoted agile only for small teams because that was where it originated. We had plenty of experience to say that agile worked well on seven- to ten-person teams. We were also quick to learn the techniques that allowed agile to scale up to around 20-40 people.

These days, though, there are many truly large projects being done with agile. In preparing for this posting I started counting on my fingers the number of 100+ person projects I’m aware of. I quickly ran out of fingers. I’ve been involved in a couple of 500+ person projects and am aware of three projects that each have over 1,000 people. We are truly at the point of doing large scale agile.

Unfortunately, the charts and tools we use for such large projects have not entirely caught up with us. For example, the time-tested Scrum burndown chart is absolutely wonderful but is really limited to showing only one thing: a single team’s rate of progress through their product backlog. This month I want to write about visualizing large product backlogs using a technique I’ve been advocating with my clients for three years but will be writing about here for the first time.

Suppose you have a very large product backlog–such as one with lots of themes (groups of related user stories) or being worked on by multiple agile teams. The best way to visualize this product backlog is with a treemap. Treemaps were invented in the 1990s by Dr. Ben Shneiderman as a way of visualizing hierarchical (that is, tree-structured) data.

The following is a simple treemap of a two-story house:

In this treemap, each rectangle is sized to represent the relative area of the room. From it you can see that the master bedroom is about twice the size of either kid’s room and a little larger than the downstairs family room. The combined green area of the downstairs rooms is slightly larger than the area of blue upstairs rooms. From this very simple treemap you can get a feel of certain aspects of this house.

To visualize a product backlog with a treemap we need to conceptualize it as hierarchical data. We can do this a couple of different ways. For example,

Rental Car Theme

As a traveler, I can rent a car
As a traveler, I can get collision insurance on a car rental policy.
As a traveler, I can request a baby car seat be inside my car.

Airplane Theme

As a traveler, I can request an aisle seat.
As a frequent flyer, I can request an upgrade to first class.

Or we could create a product backlog as a tree with levels for

Team

Product Backlog Items Being Worked On By That Team

The following figure shows a product backlog as a treemap. There are five themes in the treemap. (Theme 4 is in the top left; Theme 1 is in the bottom right. You can click on it to enlarge it but be sure t come back.) Each theme is made up of a number of individual user stories. Story 4-28 (indicating the 28th story of theme 4) is in the top left. I’ve used this “theme-dash-story” notation for simplicity only for this example. I wouldn’t do that on a real project, of course.

The size of each story in the preceding figure represents the number of story points that the story was assigned when estimated. Colors can be used on a treemap to represent an additional attribute of the data. On agile projects I’ve used colors to represent whether a user story has been developed or not. One color coding we used was:

Done
Started but not done
Not started but not planned to have been started yet
Not started but it should have been started by now
Blocked

I’ve also used color to indicate which team would work on a user story / product backlog item or whether the item was ready for development or not. Treemaps are very flexible in this regard. Check out the link to the stock market as a treemap at the end to see a great example of using color.

A good treemap is interactive–you can mouse over, click on regions of it, and so on. For example, in the treemap above you’ll notice that some of the user stories of Theme 4 are so small you can’t read them. Clicking on a part of Theme 4 should zoom the treemap in so it displays only Theme 4, meaning more room is available and more detail can be shown as below:

Sometimes zooming isn’t enough. A good treemap implementation will also display additional detail when mousing over part of it as shown in this example:

Treemaps are an excellent way of visualizing large product backlogs. To date, I’ve made use of various open source or relatively inexpensive general treemapping tools to create these on my projects or for my clients. Hopefully now some of the leading agile tool vendors begin to incorporate this type of visualization technique into their products. I would love to be able to visualize a large product backlog and interact with directly from within some of those tools. Until then, check out some of the links below for useful ways to create treemaps. The ones in this posting were created with IBM’s free Many Eyes tool.

Useful links:

Posted in Scaling Scrum/Agile, Sprint Artifacts | 15 Comments »

Improving On Traditional Release Burndown Charts

Wednesday, June 18th, 2008

I want to use this month’s blog posting to introduce a type of burndown (and burnup) chart that I find useful. I’ve been drawing this style of burndown chart for years and have coached many of my clients to do the same. Unfortunately, we’ve had to draw it either by hand or in tools like Visio and OmniGraffle because the agile tool vendors haven’t (to my knowledge) hit on this idea yet. I’m hopeful that some of them will see this posting, decide this is a good visualization, and incorporate it into their products.

The classic Scrum release burndown chart is good at showing whether a team will finish “on time” as can be seen in the following example burndown chart:

A release burndown chart such as this one shows sprints on the horizontal axis and can show story points or ideal days on the vertical. It is updated once per sprint to show the team’s net progress that sprint. A team’s net progress is the amount of work they finished net of any changes in scope. So a team that completes 30 points of work but that has 10 points added to their product backlog will show net progress of 20.

But while a traditional release burndown chart excels at showing whether a team is on pace to finishing on time, it is not very good at showing what will be included in that “on time” delivery. To see this, imagine two teams that each start with 200 story points of work. The first team finishes twenty points of work for each of ten sprints. The second team is incompetent and rather than completing twenty points each sprint they drop twenty points of scope each sprint. The two burndown charts will be identical–perfect lines descending over ten sprints from 200 to 0.

At one level this is OK: the burndown chart shows whether a team will be finished (or by when the will be finished). The simplicity of the standard release burndown chart has much in its favor.

It isn’t hard, though, to extend a release burndown chart to also show what will be in the product by the final sprint. Look at the next figure, which is a hypothetical example of an eCommerce product.

In this figure, you can see the burndown is tracked in the normal way through the end of the current sprint, the seventh. The company desires to release this product after the fourteenth two-week sprint. The right side of the burndown chart shows the team’s product backlog with the highest priority theme (“Returns”) at the top. This top block represents some “must-have” user stories related to returning purchased items. Below that is a theme for gift wrapping purchased items, followed by some “nice to have” aspects of returning items. At the bottom right is the Coupons theme.

Extending out from the team’s current position at the end of the seventh sprint are four lines. These lines represent the following:

The team’s current position, drawn as a horizontal line from the current burndown position over to the product backlog. This tells us what is in the product so far. We can see that the mandatory return user stories and the gift wrap user stories are finished and that the team is partially into the nice-to-have return user stories.
A black, dashed line showing the team’s most likely finish. This is the first of three trend lines meant to show the likely range of work the team might deliver. To draw a team’s most likely finish use the team’s long-term average velocity. You can define “long-term average velocity” in whatever way you want but my preference is to use the average velocity of the last 8-12 sprints. Pick the number of historical sprints that is most suitable for your team based on how long the sprints are and how long the team stays together.
A pessimistic forecast of the amount of functionality that may be delivered. I recommend forecasting this based on a team’s worst-case but likely velocity. Calculate this by averaging the worst three or so velocities chosen among the same 8-12 iterations you looked back at to determine the team’s long-term average velocity.
An optimistic forecast of the amount of functionality that may be delivered. Calculate this in the same was as in the pessimistic case but use the three (or so) best velocities of the team.

The figures in this blog are static images I’ve cut from a presentation. If you apply this technique for your team, the backlog items on the right should be clickable, allowing users to drill down into a product backlog theme to see specifically which items (typically user stories) make up the backlog.

By producing a single chart that shows both a team’s rate of progress (its burndown) and the product backlog, we have a single visualization that shows both when a team is likely to finish and what features will be in the product by that time. This makes is easier for product owners to make scope vs. schedule tradeoff decisions.

Check back in a few weeks when I’ll show an even more powerful technique for visualizing large product backlogs.

Posted in Agile Planning | 16 Comments »

Correct Use of a Release Sprint

Wednesday, June 27th, 2007

In Scrum we tell teams that at the each of each sprint they need to product a “potentially shippable product increment.” However, “potentially shippable” and “shippable” are not the same thing. Some large or complex projects will require the use of “release sprint” or “hardening sprint” at the end of a release cycle (say 6 two-week sprints then a 2-week release sprint). The release sprint is not a dumping ground for sloppy work; rather it is a place where some hardening of the system can occur.

A great example is a bank I work with. They have 12,000,000 lines of COBOL code that manages bank balances. They have a 1,000,000 line web application that can write to the same database as the big COBOL application. Manual testing of the COBOL system takes three weeks. The web team targets having a potentially shippable application each sprint. They end each sprint pretty sure that they haven’t messed up the COBOL system because they are conscientious developers. However, they don’t know that they haven’t messed up the COBOL system. And they do know that eventually the odds will catch up with them and given enough sprints they will eventually mess up the COBOL system somehow. So they run a release sprint every few sprints before the website goes live. They do the manual system testing that would be prohibitively expensive to do in each sprint at that time. Of course we’d all love the COBOL system testing to be an automated single-button click that could be done in each sprint but since that’s unrealistic in their situation right now it’s done during the release sprint.

If you use a release sprint be sure that the length of the release sprint is independent of the number of sprints that precede it. To continue with the team above, if they ran five regular sprints before deciding to ship the web application, they need three weeks for a release sprint. If they ran twenty regular sprints before deciding to ship, they should also need just one three-week release sprint. To say otherwise would be to plan for work (such as bugs) to slop over from one sprint to the next.

Posted in Agile Planning | 12 Comments »

Mountain Goat Software

Mike Cohn’s Blog - Succeeding with Agile