Using Story points is a technique used by Scrum team to evaluate the relative size of user stories. If this technique works fine for single teams, it might be more problematic when multiple teams are involved. In this article, Paul Raymond explains why user story normalization is needed in contexts where multiple Scrum teams cooperate on the same user stories.
Paul Raymond, Inflectra Corporation, http://www.inflectra.com/
Traditional software development estimating techniques are slow, long lasting exercises and as such are totally unsuited to Agile processes. New methods of estimating have emerged which fit the Agile model, requiring minimal effort to provide ‘just enough’ information to support prioritization and decision making. The popular unit of measurement for Agile sizing is the Story Point.
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.
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.
About the Author
Paul Raymond is a successful software program manager with Inflectra Corporation. He has extensive experience working with requirements management systems, including DOORS from Telelogic and SpiraTeam from Inflectra. Paul has helped customers in multiple industries take control of their requirements and develop actionable plans for the delivery of software projects on-time and on-budget. This article was originally published on http://www.inflectra.com/Ideas/Entry/272.aspx and is reproduced with permission from Inflectra.