by Christine Thompson
One of the biggest bones of contention that I seem to have had with my various Scrum teams is around sizing and estimating. There seems to be a level of confusion about why to size, how to size, what units to use etc. etc. Whilst there are guidelines out there (for example, see “Agile Estimating and Planning” by Mike Cohn) there is, of course, no right and wrong way to do this and teams must settle on the solution that works for them. But let’s at least review what those guidelines are, as a starting point.
Sizing User Stories
User Stories are generally estimated at a high-level, in story points. They are sized relative to each other, rather than in absolute terms. The size of the story, in story points, is a function of its complexity to implement, the effort involved and any risk associated with it. One neat example, given by an old colleague of mine, was for a user story which required the operator to hit the X key once, on the keyboard. Of course this would be low complexity and low effort but if the story increased to hitting the X key one million times, then the complexity is still the same (it’s still a simple task) but now the effort involved in significantly increased and therefore the size of the story is increased too. So both of these factors influence the relative sizing of the story, along with any risks or unknowns that it contains.
Why size the story?
I would suggest two reasons for this. The purpose of the estimate is to track velocity so that we can predict when features will be completed. If we know how many story points we can complete in a sprint, and we know how many story points remain on the backlog, we can forecast when features can be delivered. Another key purpose for sizing has to be around the conversation that this draws out of the team. For the individuals to agree on a size, they have to reach a shared understanding of what’s required in the story and they have to be able to agree the size they assign. The discussion it takes to get the individuals to reach consensus is of great value in ensuring a thorough and agreed understanding of the work. Even if we threw the estimate away at the end of the sizing there would still have been value in the exercise.
Sizing Tasks
Once we have a user story of the right size (generally 8-13 points, depending on your own ‘value’ of a story point), we will often break this down into individual tasks. This allows the team to understand the individual pieces of work that will be performed to implement the story and to be able to parallelise the work with two or more people. So what about the sizing of these tasks? Tasks are generally sized in ideal time. They are low-level and small enough to know roughly how long we will spend on them. The purpose of sizing the tasks is to allow us to burn-down work during the sprint, so that we can follow our progress and identify early if we are not on track.
So if we add up the time taken for the tasks, we can calculate how long it takes to implement a story point, right?
Wrong! Velocity is an average over time and takes a number of sprints to establish. Some stories of the same story point size will take longer to complete than others of the same size. Velocity takes into account a whole team over a period of time. Tasks relate to one person doing a small amount of work. You can’t equate the two and they serve a separate purpose.
So, in summary:
Stories are sized in Story Points which provide a high-level comparison of complexity and are externally visible to the stakeholders.
Tasks are sized in ideal time which provides a low-level measure of effort and are internally visible to the team, allowing them to track progress within a sprint.
I’ve worked with teams who cannot cope with the abstract concept of story points and need to work in the real world units of time. They estimate everything in either elapsed or in ideal time. They admit that, if forced to use story points, they will have a conversion factor in their head which will allow them to supply this. These are the teams who may benefit from a better understanding of the concept and abstraction of story points. I’ve also worked with teams who prefer to do everything in story points because they hate the idea of switching between the abstract complexities and the actual time taken. They feel that it makes them equate story points to time, which they want to avoid. This seems a slightly more understandable approach, although not always well supported in Agile project tracking software.
The final word on this, of course, has to belong to the individual team and they must do what works best for them in order to achieve their needs in terms of planning and tracking their work. If it works for them, then it isn’t broken.
