My first bit of advice is always to try to put off answering until you’re able to get even one sprint of historical data. But that’s not always possible. When it’s not my general recommendation is to conduct one or more commitment-driven sprint planning meetings and use those to forecast likely velocity.

However, some people are still more comfortable thinking in hours and rather than forecast velocity, they want to forecast the number of hours a product backlog will take. From there they will usually estimate the duration of the project (something that could be done more directly with a velocity estimate). But, since it’s a common question, I’d like to address it.

Here’s essentially the question I was asked. I’ve paraphrased, simplified and left out extraneous information:

We have no historical velocity data. We have a product backlog of 300 user stories. Each user story has been estimated, most in the range of 3-13 points. Would the following approach be reasonable:

1. Grab a random sample of 40 stories.
2. Break each of those stories into tasks and estimate the tasks.
3. From the task estimates come up with an average number of hours per story.

For example, suppose the randomly selected 40 user stories total 150 points and that the tasks identified for those 40 user stories total 600 hours. We would then theorize that it is about 4 hours per story point?

Well, yes, the idea here is fine with two problems:

1. It’s important to remember that the relationship between points and hours is not an equivalence. It is not that 1 point equals 4 hours (which is what our example showed above). It is that 1 point equals a mean of four hours with a standard deviation of plus or minus say 45 minutes. This would mean that most of the time (68% of the time) the relationship would be that 1 point takes from 3:15 to 4:45 to finish. It would mean that almost always (98% of the time), one point would take between 2-1/2 and 5-1/2 hours to finish (two standard deviations).
2. The above approach assumes that 1-point stories and 13-point stories are estimated perfectly in relative terms. In other words, it assumes that if the mean duration of a one-point story is 4 hours, the mean of a 13-point story will be 13×4=52 hours. For many reasons, this is unlikely to be true. And the data I’ve collected from a variety of teams, shows that–as we’d expect–teams are not perfect, even though many are amazingly consistent.

So, what can we do to address these problems? A first really simple improvement is to calculate the average number of hours for stories of each size rather than one overall average. For example, in the example above we said that the 40 stories were 150 points in total and 600 hours for an average of 4 hours per point. But, if we averaged the 1-point stories on their own we might find that they were 3.2 hours per point, and the 2-point stories that were broken into tasks were 4.3 hours per point, and the 3-point stories were 4.1 hours, and so on.

We can then multiply that average number of hours by the number of stories on the product backlog of each size. An example using the average hours given above is shown in the following table:

First, notice in the above that the second column is hours per story, not hours per point. The two-point stories were assumed to take 4.3 hours per point so 8.6 (4.3×2) hours per story is shown in that column.

This table shows that we have five 1-point user stories. Each is expected to be about 3.2 hours so we expect to spend 16 hours total on the 1-point stories. Summing the last column in this table gives an expected total of 170.9 hours.

Note that this approach is subject to all the shortcomings that will have been introduced during the task identification and estimation step. Most importantly that the team will fail to identify all tasks. So this approach will estimate the number of hours to deliver the tasks identified. Some adjustment will need to be made to estimate the amount of work that the team failed to identify and the duration adjusted accordingly.

I’ll write about other improvements to this simple approach in upcoming blog posts.

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 project management approaches avoid this “bogging down” by realizing that, while some anticipation is necessary, 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.

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.

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.

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

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 to be a very helpful agile project management tool. 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.

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.

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:

This graph shows a team calculating three average velocities:

1. Long term average, defined as the mean of the last eight sprints
2. Worst case average, defined as the mean of the worst three chosen among the last eight sprints
3. 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:

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.

But what do we do when we are managing an agile project where 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:

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

(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:

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.

These days, though, there are many truly large projects being done with agile methodologies. 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:

1. Done
2. Started but not done
3. Not started but not planned to have been started yet
4. Not started but it should have been started by now
5. 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:

1. The stock market as a treemap
2. IBM’s Free Many Eyes tool
3. A good interactive example of a treemap
4. Read news headlines as a treemap
5. A simple JavaScript implementation you could add to your project homepage

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:

1. 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.
2. 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.
3. 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.
4. 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.