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.
Our mission to helping our customers - large corporations, small businesses, professional services firms, government agencies and individual developers – with the means to effectively and affordably manage their software development and testing lifecycles, so as to decrease the time to market and increase return on investment.
At Inflectra, we are fully committed to provide our customers with the very best products and customer service. We believe in going the extra mile to ensure that each customer is satisfied with our software products. We have the experience and the commitment to deliver the products customers need to deliver their projects and assure quality every step of the way. (Learn More)
We are so confident that you will be fully satisfied with our products that we offer a 30-day, unconditional, money back guarantee! (Learn More)