Since you need to know what progress the team has made since the previous portfolio evaluation, you need to see current velocity and his- torical velocity. If your project team has been working in the rhythm of a timebox for a number of iterations, understands how to break down requirements into small user stories, and knows what “done” means, their velocity might look like this:
# Story Points Done/Iteration
0 1 2 3 4 5 6 7 8 9 10
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 Iteration
Story Points Done
Velocity of user stories or points per iteration is an important measure, but it doesn’t paint the whole picture. You also need to see how many stories are being added to the backlog. If the product owner is contin- ually adding many items to the backlog for this project, you need to reassess the size or the strategic importance of the project.2
Here, the backlog growth is small over the project. The team continues to make progress. There is no issue with this project, as long it remains strategically important.
2. Frequent additions to the backlog could also indicate that the product owner doesn’t understand the purpose of a backlog for a release.
MEASUREPROJECTVELOCITY: CURRENT ANDHISTORICAL 145
How Close to Completion Project Is
0 20 40 60 80 100 120 140 160 180
1 3 5 7 9 11 13 15 17 19 21 23 25 Iteration
Story Points
# Points Left to Do Total Points
Running Sum Points Completed
Teams who are newer to agile will need a few iterations until their veloc- ity becomes regular. The first three iterations tend to be random and not predictable of future velocity. And, given that people are just learning how to break features into relatively smaller stories and how to define
“done” for their projects, it may take even longer than three iterations—
I’ve seen teams take nine or ten iterations—until you have a velocity that helps you predict the future. However, even unpredictable velocity helps you see what the team has accomplished, so it can be a valuable measurement. Just be careful of using it as a perfect predictor of future progress. There is no perfect predictor.
# Story Points Done/Iteration
0 1 2 3 4 5 6 7 8 9 10
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 Iteration
Story Points Done
When the team has an unpredictable velocity, you will see the effect in the backlog completion chart. You can see in this next figure that this team required a few extra iterations to finish the project, because they had an erratic velocity. But even with an unpredictable velocity, you
MEASUREPROJECTVELOCITY: CURRENT ANDHISTORICAL 146
would still have data to evaluate the project’s progress, especially if you also saw a product demo.
How Close to Completion Project Is
0 20 40 60 80 100 120 140 160 180
1 3 5 7 9 11 13 15 17 19 21 23 25 27 29
Iteration
Story Points
# Story Points Left to Do Total Story Points Running Sum Story Points
If your team is having trouble using velocity as a predictor, make sure no one is adding new stories to an iteration underway, and encourage the team to report other obstacles so you can see whether technical debt is preventing them from making a more predictable progress. Ask the team to report how much work in progress they have, as in Sec- tion 10.4, Measure Cumulative Flow for the Project, on the next page.
And, make sure the team is not using a serial life cycle. You can see the results for this team that started using a serial life cycle for a few iterations:
How Close to Completion Project Is
0 20 40 60 80 100 120 140 160 180
1 3 5 7 9 11 13 15 17 19 21 23 25
Iteration
User Stories
# User Stories Left to Do Total User Stories Running Sum User Stories Completed
MEASURECUMULATIVEFLOW FOR THEPROJECT 147
The team decided they needed several architectural iterations at the beginning of the project. The manager explained that without visible progress, the project would be canceled. (PowerPoint architecture, as defined in Practices of an Agile Developer: Working in the Real World [SH06], was not visible progress.) The team decided it was time to finish a few features, starting in the fourth iteration.
You might hear team members say, “We have to get the architecture/
infrastructure right before we start.” Teams who are new to agile do believe this—you might, too. But, my experience with agile teams, and other people’s experience with agile teams who use collective code own- ership, has found that youcangrow the architecture or infrastructure as you proceed building features. SeeManage It!andExtreme Program- ming Explained [Bec00] for suggestions on how to start a project with- out a lot of architecture work up front, and see Refactoring: Improv- ing the Design of Existing Code [FBB+99] and Refactoring to Patterns [Ker04] for how to evolve the architecture as you proceed. You might need some time to evaluate the architecture. But you don’t need an entire iteration devoted to architecture. Your project will turn into a serial life-cycle project, which makes it difficult to evaluate in a regular short time period as part of a portfolio.
But what happens when a project doesn’t show any velocity at all for several iterations? That’s when you must ask questions in your portfolio evaluation meeting about the project, about its strategic importance, and about whether the project is possible to finish. And, it’s time to measure work in progress. Instead of finishing features, your team may have substantial work in progress. That doesn’t provide value to the organization and may be invisible to the team.