Understanding progress: on points, velocity and when to add new stories

Building software takes time. Usually enough time that people are interested in monitoring progress and understanding when it will be done. Agile teams often use User Stories as a unit of work. Typically these are estimated in points enabling a team to record their velocity, that is, the number of points completed per sprint.

With this data, teams have a simple means to show progress. Interested parties can follow along quite easily, seeing how each sprint eats away at the features in the backlog and how many points are left to complete the product. Using the team’s average velocity will give a nice indication of how many more sprints are required to complete the features in the backlog: points remaining ÷ average velocity = sprints remaining.

There is one wrinkle to this otherwise simple scheme. As anyone who has developed software can tell you, the devil is in the detail. Something that initially looks simple can end up being more involved than originally estimated. Case in point: my team recently had a story like the following for a desktop client image processing product they are building:

 
     As an imaging assistant
     I want to be able to open JPG images
     So that I can process them

The story seemed to be straightforward and was implemented easily and quickly. All was well until we tried some particularly large JPG files. At this point things blew up with out of memory errors and the like.

So was handling large JPGs a new feature and thus a new story? Or was it obviously part and parcel of the original? In other words, the question is how do you deal with this and still report easily understandable progress?

The short answer is it doesn’t really matter. You can add new stories to the product to cover the new work that you discover. Or you can just do the work that was implied but not necessarily obvious from the original story. The formula for figuring out how many sprints remain still works either way. Taking the former approach your velocity is likely to remain fairly stable. Taking the latter approach you may see it bounce around a little bit more, or see it dip from historic levels if the team had a velocity established through more predictable types of work (e.g. maintenance on a well known product.)

The longer answer is that each approach has its own pros and cons. Depending on your situation one may be better than the other.

Adding a story, pros:

• Stakeholders can see the amount of work we original imagined was involved has grown and have more chance to comment on the necessity of these items – perhaps the complexities and edge cases discovered aren’t that valuable.
• It probably shouldn't matter, but velocity remains stable and nobody feels the need to cross-examine the team and ask "Why has your velocity dropped?" Done this way velocity may even serve as a crude indicator of team performance and improvements can be seen in higher velocity.

Adding a story, cons:

• It probably shouldn't matter, but there's likely a class of stakeholder that will question why all this "extra" work is emerging and ask how come we failed to identify it in the first place.
• If the team has the pleasure of using a computerized agile lifecycle management tool then each additional story is another thing to enter, estimate, prioritize, track and update status on etc.
• The number of points to complete the originally envisaged release keeps growing making some people anxious: "We don't know how much work is left to do, how can you ever hope to predict when it will be done?"

Not adding a story, pros:

• Nothing extra to track (though we probably need to clarify the acceptance criteria of the original story)
• Number of points to complete original feature set for the release remains the same (unless we discover a need for genuinely new features)

Not adding a story, cons:

• The potential roasting of the team: "Why is your velocity erratic/dropping?"
• The team might miss an opportunity to push low value work down the backlog.

Personally I'm most strongly drawn to the idea of not adding in extra stories. I like the simplicity and minimalism of this. The more items there are in the backlog the harder it is to grok the thing as a whole and more busywork goes into managing it all. I don’t think the “pros” of adding in extra stories are powerful enough to make it the preferred approach. And although there is the potential “con” of the team getting questioned about why their velocity is erratic or dropping, I believe this can be explained quickly in simple terms. I also think it’s a lot more straightforward, even comforting, for stakeholders to see that the size of the backlog remains fairly stable unless things they too understand as new work (features) get added.

When average is good

Calling something average is one step removed from calling it mediocre. But in the mathematical sense, especially when applied to a team’s velocity it’s a good thing.

One of the certain tricky bits for any new team trying out scrum is establishing the team’s capacity. That is, without an historic record of how many story points of work a team can complete you are somewhat in the dark as to what to aim for come sprint one.

For a team that’s been working together in the past but not estimating in points it’s possible they may have a fairly accurate gut feel for things, and that can be your guide. There’s likely still the novelty of having not just to develop but also test, fix defects and truly complete (according to your definition of done) but, with experience of working together in the past a decent guess can be made.

For a newly assembled team however, or one that’s less confident in figuring out how much of the backlog to bite off initially, my advice would simply be don’t worry. Just pick more than enough and accept that you won’t make it all. From what I’ve seen the first few sprints are very much a learning experience and part of that learning is going to include figuring out your capacity.

Given just three or four sprints the team, with good coaching and guidance from a competent scrum master, will have figured out a number of recurring key items: big stories are bad, transparency between those that code and those that test is key, getting things “done” means limiting how much you work on concurrently and, ultimately, a reasonable average velocity to work with for planning future sprints.

The team I am currently working with had quite an erratic velocity initially: 16, 8, 49 (yes really!) and then 26 points. After this we have stabilized nicely with an average of 24 points a sprint.

This “we dunno, we’re just gonna try it and see” approach to working out a team’s capacity for quality work is inarguably logical. However it doesn’t necessarily sit well with those from a command and control background, especially those with management responsibilities for the team new to scrum. They like detailed planning. Predictability. Commitments. Maybe even punitive action against teams that “fail”.

This is completely the wrong approach.

Like it or not, this is when managers need to decide if they are truly supporting scrum or not. If you are, then step up. Provide the environment your team needs in this early phase of the adoption. Make them comfortable with the new regime of trying, reflecting, learning and improving. Without that support you will stifle their ability to rapidly improve, and in turn lead to a less than stellar scrum implementation. Maybe even to a failed one. This happens a lot, and people revert to traditional, comfortable but ultimately unsatisfactory approaches to building software. Don’t let this happen to your team. Create the right environment and harness the power of average.