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 is 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.
Shawn Belling, M.S., PMP, PMI-ACP, CSP, is a globally-experienced project management practitioner and instructor. He is a senior consultant for Farwell Project Advisors LLC and has held executive and management roles in software, consulting, bio-pharma, manufacturing, and regulatory compliance sectors. Shawn is also adjunct faculty at the University of Wisconsin with over 25 years of project and program management leadership experience. He teaches, speaks and consults on various project management topics and was awarded a PMI Kerzner Scholarship in 2008. Shawn writes about methodologies and project planning.