Agile practitioners often bring differing points of view on their sizing scales for feature and story point estimating. It is important for scrum masters, product owners, and teams not to get too granular or outsmart themselves when developing their relative sizing scales. Effective agile teams need to arrive at a simple, repeatable agile estimation scale for feature-level sizing and for story point estimating.
There are many reasons why the feature and story sizing scale developed by an agile team is so important to successful release delivery. This estimating scale touches every facet of the release as well as each sprint. Given its importance, it is worth reviewing some specific reasons why agile teams need to develop and refine a workable story point estimating scale:
- For rapid high-level sizing of features for initial slotting in release plans.
- For release and sprint capacity planning.
- To inform prioritization decisions by the product owner.
- To enable strategic decision-making by the leadership team.
- To eliminate reliance on individuals to do the team’s estimating.
- To leverage a team’s collective experience and memory for assessment and estimation of capacity for future work.
- To enable and require teams to rapidly and iteratively estimate and commit to work within their sprints.
- To enable ongoing and reasonably accurate measurements and predictions of current and future performance.
- To acknowledge the inherent uncertainties involved in estimating projects through the use of a relative sizing scale and through iterative re-estimating.
For agile to work effectively and deliver the rapid value realization benefits expected, teams must be able to estimate quickly and simply and feel confident in their estimates to make commitments. Experienced agile practitioners and coaches recommend a less granular versus more granular estimating scale for sizing of features and user stories. For example, scales that span 1 – 100 are too granular to be effective. Sizing one story at “59 points” and another at “62 points” implies a level of precision and certainty that is not realistic nor necessary when sizing features and stories. Teams new to relative sizing would do better to start with an approach like T-shirt sizing – XS, S, M, L, XL – and eventually convert these to a numeric scale with the help of an experienced scrum master or coach.
Organizations and teams new to agile often struggle with the concept of sizing their work using methods other than hours of effort. Experienced agile coaches, scrum masters, and trainers know this and work with teams to help them cope with this. They teach teams that story point estimating considers the effort, duration, risk, and overall complexity to size features and user stories relative to one another. Estimates of effort in hours are appropriate when teams break their committed stories into smaller tasks in the final steps of sprint planning. Estimating the hours for the tasks required for each story is a checkpoint prior to finalizing the sprint. It gives the team an opportunity to see how the story point scale aligns with the hours and ensures in a practical way that those hours are available in the upcoming sprint.
Project sponsors and product owners sometimes want to convert the story point scale to hours or some other metric for their own purposes. For example, take the project sponsor on a web content management implementation project who was very pleased when she found a way to convert the team’s story points to hours but got fired before the project was finished – partly because the project was late, but also because she used her own scale to second-guess the team’s estimates and progress.
The sizing scale is first and foremost for the use and benefit of the agile team – they are accountable for their commitments and need a simple and reliable way of estimating the work and their capacity. The iterative cycles of agile ensure that this method becomes more reliable with each sprint. The product owner, project sponsor, and leadership team also leverage the sizing scale to make critical decisions and ensure realistic commitments to internal and external customers. Through effective sizing and prioritization, agile organizations can consistently improve and realize rapid value creation.