August 26th, 2014 by Adam Sandman
Unlike traditional units of software sizing such as hours, days and lines of code, which are taken from the real world and therefore easily understood, Story Points are an abstract concept and so take somewhat longer to get used to. Hours, days and lines of code are pre-defined; nobody has to explain what an hour is. Yes, it’s true that an hour could mean an hour on the clock or it could mean only the available time an engineer works per hour which would be more like 50 minutes taking into account coffee breaks and other distractions, but the point is, the concept is well understood.
Story Points, on the other hand, being abstract, require that a team agree on the definition of 1 story point and relate all other estimates to that. The simplest way to do this is to pick a small story that is well known to the team and call that one story point. The problem with this idea is that it only works within a team. With multiple teams, each may pick a different size for their story point reference so that their estimates will be on a different scale to those of all other teams.
What Happens with Multiple Teams?
Does this matter? Well, it doesn’t, provided each team operates fully independently of all others. Stories must be allocated to a team before they are estimated and this becomes the backlog for that team only. Once estimated, stories cannot simply be allocated to another team because the estimate for the story has no meaning in the context of a team with a different story point measure. Further, each team is likely to have a different velocity (story points the team can complete per iteration.)
In a project where stories are going to be interchangeable between teams, it is important to have a common story point size. Achieving this is called normalization, which is described in the whitepaper - An Introduction to Agile Estimation.
The bottom line is that normalization is meaningless on projects with a single unified team or on multi-team projects where teams are fully autonomous. But, whenever stories are going to be dynamically allocated to teams or whenever there is the need for meaningful aggregate reports of progress, then normalization and the resulting common definition of a story point are essential.
You may also be interested in:
An Introduction to Agile Estimation
Requirements Sign-Off
Is Agile Product Management Dead?
Documenting Requirements in Agile Projects