A lot of doubts regarding Scrum are about estimation in a Dynamic environment. One uses Scrum because the effort underway is Unique. It requires an empirical process control. Desiring a very accurate estimate is a waste of time. Hence, for coarse estimates, we have just one variable called Story point. During the initial meetings, The Scrum Master interviews the Scrum Team, understands the perspective for one of the User stories that is easier than the others and assigns it a Story Point estimate. The Scrum Master never again discusses the parameters of what one story point is based on real life complexity or even enters the debate. Story point is now a variable that has linear relationship with various project parameters like time and risk. This one factor can then be multiplied with time, cost and other factors to obtain Coarse estimates. This is sufficient information for the Product Owner to guide the Prioritization of Product Backlog and plan releases. A User Story is an abstract construct which is more durable than fine details which may change till the Sprint planning meeting and even beyond. Only when we add the User Story to our Sprint Backlog in Sprint planning do we need detailed estimates and look at real world units like Man-hours and Sigmas.
Relative estimation takes out the element of haggling which might occur as the Customer and Scrum Master may have different Ideas of what the correct estimate for effort required for a feature may be. Also, as much as possible, the Story points must be assigned as whole numbers. This means that instead of overanalyzing whether the effort is worth 2.3 story points or 2.28976, the team can assign either 2 or 3 and get on with the actual productive tasks.
Story points have utility even beyond the Sprint Planning Meeting. They are part of two essential metrics to measure project progress.
- Team velocity—Number of story points done in a given Sprint
- Done success rate—Percentage of story points that have been Done versus those committed
Story points give the advantage of being consistent and thus communication can be simple. Velocity based on Story points is stable and accounts for changes in resource allocation to the project during its life time. The Program Product Owner and the Scrum guidance body can still track teams that are under/over performing and the Customer can be assured with data that the project is/isn’t on track. There is less waste of effort in estimation and misunderstanding in Dynamic environments. In agile contracts like an Incremental delivery Contract, a story point may the factor on which billing is done.