I often find that teams implementing Scrum have questions about how best to track progress. There are several different commonly used options. Some teams divide each story into tasks of one-day duration. Well, they try to; actually, I've seen teams run into a lot of impediments that way. That's natural, because some activities demand much less time, while many require two days or more.
Other teams explode each story in different activities and make a significant effort to estimate how many story points go into each of those activities. This is done during the planning meeting, which therefore lasts four to six hours. Let's name this scenario "Story Points Distribution" for future reference.
A third approach is the one I like best. I consider it the most beneficial, and it doesn't require a large amount of effort. This makes it consistent with other aspects of Scrum (such as use of the Fibonacci sequence or powers of two sequences during estimation) that help teams avoid investing too much effort trying to get to an apparent precision.
This approach, which I recommend every time I have the opportunity, is to measure progress based on a continually updated ETC (estimate-to-complete) for each story. You can use the approach at the end of every daily stand-up meeting -- or during the meeting itself, if timeboxing is something you've already mastered. The idea is basically this: Let the team estimate the number of story points remaining to get a certain user story completed. Do this every day.
Let's look at an example. Say we have a two-week sprint. After the planning meeting, the committed backlog is seven user stories, from A to G (Figure 1).
Fig. 1
After making some progress during Monday afternoon, the team gathers on Tuesday morning for the daily stand-up meeting. The group estimates the ETC (remaining work) for the stories that are still in process. As seen in Figure 2, stories A and B are in progress and have been reestimated. The basis for this is what remains of the entire story, not the activities or tasks identified for it. It is this estimate that the team uses to render the burn-down chart (Figure 3).
Every day continues in this manner, with the team estimating a new ETC for each in-progress story. Figure 4 illustrates the resulting estimates, while Figure 5 shows the burn-down chart at the end of the sprint.
One of the arguments I often hear is, "But the ETCs are not 100-percent accurate." That's absolutely true. No estimate is 100-percent accurate. But estimating the ETCs of in-process stories every day gets you closer to the actual effort required than does dividing the story points among all the activities at the beginning of the sprint and adding up the remaining activities every day. Why is that?
We can explain it with the Cone of Uncertainty Theory: "In project management, the Cone of Uncertainty describes the evolution of the amount of uncertainty during a project. At the beginning of a project, comparatively little is known about the product or work results, and so estimates are subject to large uncertainty. As more research and development is done, more information is learned about the project, and the uncertainty then tends to decrease." (http://en.wikipedia.org/wiki/Cone_of_Uncertainty)
As you can guess, the Cone of Uncertainty is strongly based on traditional project management. Nonetheless, its principles apply to Agile project management.
Remember the Story Points Distribution scenario? (Divide the estimate of a user story down into its activities.) We can say that we already have a good amount of certainty -- let's say +/-25 percent (1.25/0.75). Of course, this effort doesn't give back estimates that are 100-percent accurate. While the team develops the product, they'll note the completed activities and summarize the ones still in progress, in order to quantify the remaining effort needed. The problem here is that, without a reestimation, we get stuck at the +/-25 percent point of the cone, although we now have lot more information than when we first estimated the story and activities.
But what happens if we don't distribute the story points among the activities? We won't have activities to add up in order to find the ETCs. However, we will have to estimate the remaining effort needed to complete each in-process story. This way we guarantee that we aren't carrying forward that +/-25 percent error we get when estimating the stories. We'll be moving to the right of the cone, getting closer to 0 percent. Estimating the ETCs while developing the product is much more accurate than simply maintaining the estimates done during the planning meeting.
I encourage teams to give this approach a try on the next sprint. If everything goes as it should, you'll quickly notice the benefits of continually evaluating story ETCs.
Share on LinkedIn
Share on Twitter
15