I have been a strong advocate over the years of using Story Points to track team velocity. In spite of many of the self-inflicted problems teams face when using Story Points (e.g., trying to initially assign some measure of time to a Story Point, or trying to normalize Story Points across teams, or confusing Story Points and task-hours, etc.), when used correctly, Story Points (and the velocity calculations they enable) make project tracking and projection incredibly easy and relatively accurate as well. (As a side note, check out the following article by Jeff Sutherland: link.)

What I’d like to cover in this posting is that using Story Points is not the only way to track a team’s velocity. For teams that have been writing User Stories for a while, and who have gotten good at breaking their work down into small enough chunks such that one or more stories can be completed (“Done!”) in an iteration, I would like to recommend that they forego the effort of sizing User Stories with Story Points. They’ve already shown that they know how to start with an Epic, and break an Epic down into User Stories that can be completed in an iteration. Thus, they’ve demonstrated that they have a relative amount of uniformity in the way that they come up with their backlog of User Stories – their stories are all in the same range regarding the amount of time and effort required to complete each one of them.

With that in mind, such teams could simply measure velocity based on completed User Stories – the principle is the same as Story Points, but mature teams can fore-go the effort required to size each User Story with Story Points (e.g., through Planning Poker).

Let me give a couple of examples – the first one using Story Points. Team A has 50 Story Point’s worth of User Stories on its backlog, and they’ve demonstrated over the course of time that they can generally complete about 10 Story Point’s worth of stories in an iteration (velocity = 10). In order to determine how long it will take to complete the remaining stories, it’s easy to divide 50 by 10 and come up with an estimate of around 5 iterations. If a customer is asking how long before the team can get to a feature that the customer is interested in, and the User Story associated with that feature appears about 30 points down the rank-ordered backlog of stories, then the team can tell the customer that it will be about 3 iterations (30 divided by 10).

The second example is that Team B has 10 stories on its backlog and they’ve demonstrated that they typically complete about 2 User Stories every iteration (velocity = 2). To determine how long it will take to complete the remaining stories, divide 10 by 2 and come up with an estimate of 5 iterations. If a customer is asking how long before the team can get to a feature that the customer is interested in, and the User Story associated with that feature appears about 6 stories down the rank-ordered backlog of stories, then the team can tell the customer that it will be about 3 iterations (6 divided by 2).

If you’re part of a fairly experienced team, and if your team already has an established velocity, consider trying this approach in lieu of assigning Story Points – it can help save some time by not going through the sizing exercises. However, if your team is fairly new to writing and sizing User Stories, or if your team doesn’t yet have an established velocity, I would recommend sticking with Story Points for now because the process of assigning Story Points (during a Planning Poker exercise, for example) is *very* helpful in aligning a team’s thinking, as well as building team synergy, as the team goes through the process of having the discussions that naturally arise when sizing stories.

As always, please feel free to comment, provide suggestions and recommendations, or even tell us about your experiences using Story Points and/or other ways of tracking velocity. Thanks!

Velocity is a great tool for agile teams but it is easy to "over-engineer" the concept -- or even misuse it. Velocity is a mechanism to understand the pace of a team that uses story points to size their user stories.

First, a quick comment regarding story points – Leslie and I advocate the usage of “unit-less” sizings of user stories, meaning that story points are not associated with any measure of time. Story points are simply an assignment of size relative to other user stories that a team works on. Thus, a 3-point story should take approximately 3 times the amount of effort for the team as a 1-point story -- irrespective of how long it takes to complete either one. Note that story point sizings are just relative sizings and they work no matter how long it takes to actually complete a given story of a given size.

Back to velocity… Velocity, simply put, is the term used to describe a team’s observed capacity for completing work. Velocity is calculated by taking the average number of story points a team completes each iteration. For example, if a team completes 8 story points’ worth of user stories in its first iteration, 12 in the second, and 10 in its third, then the team’s velocity is 10 (the average of 8, 12, and 10). Note that several iterations had to be completed first in order for the team to determine its velocity (we advocate a minimum of three iterations before starting to use velocity for project planning and tracking).

Even though the concept is simple, I’ve seen teams misuse velocity and, as a consequence, reduce its value. I’ll address three of the most common misuses in the following paragraphs:

First, velocity is incorrectly used as a "report-card" each iteration. Assume the example I used above where the team has a velocity of 10. Let’s say that their next iteration they complete 6 story points. In organizations where velocity is not understood, the team will likely be called on the carpet and asked to explain what happened (the thought being that their productivity dropped by 40%!). Given that the assignment of story points is an estimation technique and not something to be measured to 26 digits of precision, there should be an understanding that the number of points a team completes each iteration will vary from iteration to iteration. Perhaps in this iteration the team is working on a story that they underestimated. Big deal… Chances are in a subsequent iteration they’ll work on a story that was overestimated. Over the course of several iterations, the team's velocity will average out. Please do not use the number of story points a team completes in any given iteration as a report-card. Use the average and save everyone a lot of headaches from micromanagement.

Secondly, and closely related to the first, is teams erroneously claiming "partial credit" for a story. When teams are seeing the number of story points completed in a given iteration used as report-card, they tend to start trying to claim partial-credit for an incomplete story. In this scenario a team might say, “We got the code done, so that’s worth 2-points out of this 5-point story.” Even though the testing, defect fixing, automation, etc., hasn’t yet been completed, they're just trying to boost the total number of points claimed in the iteration. Unfortunately, this approach defeats a number of benefits of adopting agile. First, it breaks down team synergy by reverting back to an us-vs.-them mentality. When the whole team gets “credit” for completing a user story when it’s actually complete, then the team is motivated to help each other out. If partial credit is allowed, then this can pit parts of the team against other parts. The second problem with this approach is that it violates the agile principle of working software as the measure of progress. Code that has been written, but is untested, is not “working software.” Code that has been written and tested, but where defects haven’t been fixed, is not “working software.” Working software should be the focus for the team… And let me close this section with another simple example: let’s say a team is targeting completion of two 5-point stories this iteration (their velocity has been ~10 points an iteration, so targeting 10 points’ worth of stories makes good sense). Let’s say they complete the first story and are almost complete with the second. If the team tries to take partial credit, they might claim 4 of the 5 points for the second story and, thus, their story point totals for this iteration would be 9. Next iteration, they’d plan to finish off the last bit of the second story and then, most likely target and additional 10 points' worth of new stories (since they have been averaging 10 story points so far and they almost completed 10 points last iteration). Let’s say they complete all that work in the next iteration for a total of 11 points. What’s their velocity for the two iterations? It’s 10. Now let’s take the “no partial credit” approach. The team would get 5 story points for its first iteration and 15 for its second. What’s the velocity for the two iterations calculated this way? Right, it’s also 10. This is why focusing on velocity as an average is so liberating for teams – they’re not constantly under the microscope and don’t feel compelled to play games with partial credit.

The last abuse of story points and velocity that I’ve seen is that teams get their velocity "dictated" to them. They’re told to achieve some level of velocity before even knowing what their velocity is. Remember, as mentioned at the opening, velocity reflects the team’s observed capacity to complete work each iteration. Typically, when teams are dictated a velocity, its in “fixed content/fixed date” projects (which are anathema in agile). Teams wind up working tremendous amounts of overtime to meet their dictated velocity (which is also anathema to agile).

Finally, there are legitimate ways to go about increasing velocity, as well as illegitimate ways. The most prevalent illegitimate way is forcing a team to do overtime – this is not sustainable and will only cause problems down the road. The legitimate ways to increase velocity is to pursue what I call “enabling” practices: increasing test automation, improving builds by adopting continuous integration, adopting test-driven development and pair-programming, automating provisioning of test environments, automating deployments, and many others. Yes, putting effort into maturing these practices may mean you slow down the amount of functionality you produce in the short run, but the long-term benefits (such as sustained velocity improvements) will be well worth the initial investment. Velocity is simple - keep it simple. Increasing velocity is where the hard work is.

In one of my blog postings just over a year ago I suggested that mature teams may not need to use Story Points. However, at the end of that post, I wrote:

[If] your team is fairly new to writing and sizing User Stories, or if your team doesn’t yet have an established velocity, I would recommend sticking with Story Points for now because the process of assigning Story Points (during a Planning Poker exercise, for example) is *very* helpful in aligning a team’s thinking, as well as building team synergy, as the team goes through the process of having the discussions that naturally arise when sizing stories.

What I’d like to do with this post is cover a few issues on how to make sure you’re getting the most out of using Planning Poker.

First, keep in mind that Planning Poker is meant to be a very simple and quick process to be used by a team for assigning Story Points to a given story. It’s not meant to provide absolute precision regarding the assignment of Story Points, and the assignment of Story Points itself is meant to be relative to the sizings given to other User Stories on your team’s backlog.

Next, because Planning Poker is an estimation technique please don’t assume that everyone on the team must be 100% in agreement with the number of Story Points being assigned to a given Story. Let me explain: typically, when a team uses Planning Poker to assign Points to a User Story, there will be a smattering of “votes.” As an example, let’s say that, after the very first vote for a given Story, there are a couple of 3's, a 5, a couple of 8’s, and a 13. The scrum master should ask why folks who voted 3 thought the size was relatively small, and then ask the person who voted 13 why he thought the size was relatively big (i.e., over 4 times the estimated size of those who voted 3). After a brief discussion, the scrum master should ask for the team to vote again. Let’s say this time there’s one 3, several 5’s, and a couple of 8’s. A good scrum master should say something like, “OK team, let’s go with a 5 for this story and move on to the next story on the backlog.” What the scrum master is looking for is “harmonic convergence.” Notice how, in the second vote, there were fewer 3’s and the 13 went away. The bulk of the votes were gravitating towards a 5, and so you can see the team is getting closer (“converging”) on a given number. Good enough! Don’t waste time by voting again, and again, and again, and again (ad infinitum and ad nauseum) until the team members all vote the same – it’s not worth it. Estimation is not meant to be precise, and spending more and more time trying to be precise with estimates is a waste of time.

And here’s the main point that I’d like to make – let’s say you’re one of the team members who voted an 8 for this story even though the number finally assigned was a 5 – should you be upset? Should you start an argument? Should you want to keep voting until everyone agrees with you and assigns the Story an 8? No, no, and no. Even though you may really think the story should have been sized at an 8, you can see the team was converging on a 5, so just let it go and press on. Planning poker is not a contact sport.

Finally, once teams get the hang of Planning Poker, most of them vote no more than twice on any given story, and they usually don’t spend more than just a couple of minutes per story. Here’s the high-level process:

Step 1. If you've not assigned Story Points to any User Stories on your backlog then, as a team, quickly pick out what you all think is the smallest story on the backlog and automatically assign it a 1. All other Stories on the backlog will be sized relative to this Story.

Step 2. Grab the next User Story from the backlog.

Step 3. Have a brief discussion about the Story regarding the anticipated effort relative to the first story (the story itself should be familiar to the team since, if the writing of the Stories was done correctly, the team participated together in the writing of the given Story).

Step 4. Vote.

Step 5. If there appears to be a fairly strong consensus on a given number, go with that number, and then go back to Step 2….

Step 6. Otherwise, if there’s a fair amount of disparity in the votes cast, then have another brief discussion focusing on asking those who voted with the lowest number, and those who voted with the highest number, to give some insights into their respective thinking.

Step 7. Vote again – you’ll likely see some harmonic convergence on a specific number after the second vote, and then just go with that number. Now go back to Step 2 (lather, rinse, repeat)….

In sum, Planning Poker is a great technique to use to quickly assign Story Points to your User Stories. Just be sure that the team doesn’t over-engineer its use.

As always, please feel free to ask questions and share your experiences. Leslie and I look forward to hearing from you!

When a project is big enough to have two or more teams working on the same project, we recommend that each team have its own backlog of User Stories and each team size its own stories with Story Points. Of course, this inevitably raises the idea of having each team conform to some “story point standard” so that project progress and team progress can be tracked "uniformly." Doing this more or less means that teams have to normalize story points across all the teams so that, for example, a 5-point story for one team is the same as a 5-point story for every other team on the project; an 8-point story is the same for every team, etc., etc., etc.

All I have to say to this idea is: “Ugggghhh… What a collosal waste of time!" I’ve seen teams try to do this and the effort put into trying to ensure uniformity of sizings across multiple teams is enormous.

I’m happy to report that there’s an easier way that still allows for overall project progress to be easily seen as well as individual team progress. In essence, instead of normalizing based on story points we suggest “normalizing” based on the calendar. Let me explain: let’s assume, for example, there are two teams on a project, each having its own backlog that has been sized with story points. Team A has 2000 story points on its backlog and Team B has 500. In this case you would have three burndown charts to track progress: one that’s combined (showing 2500 total points), a second one for just Team A (showing 2000 total points), and a third one for just Team B (showing just 500 points). In order to determine relative progress for Team A and Team B, you base it on the number of points completed vs. the number of iterations... Thus, if you're half-way through the project (e.g., 5 of 10 planned iterations are complete), you would expect Team A to be ~1000 points complete (50% of its total) and Team B to be ~250 points complete (50% of its total).

Where things get to be a little more complicated is when you have numerous teams working on a project (for some enterprise application projects we’ve worked with, we’ve seen over 40 teams working on the same project). With two teams, it’s fairly easy to bounce back and forth between Team A’s release burndown chart and Team B’s release burndown chart. When you have more than that, you can create a very simple chart (using any spreadsheet tool) that shows “percent calendar complete” and “percent story points complete” for each team. Following are two examples that we’ve used (they show the same data, just in different formats):

Figure 1

Figure 2

You’ll notice in the first chart that the schedule is 60% complete (the black bars) and then each team’s relative progress is shown. In the second chart, a stacked bar is used to show overall team progress. In this made-up example, Team 1 is slightly ahead, Team 5 is slightly behind, and the other teams are perhaps struggling...

I’m sure you can think of other, different ways of showing the data, so do whatever’s most helpful. The key is that this approach is so much easier and simpler than trying to normalize the sizing of story points across multiple teams.