By: Shawn Belling
Agile practitioners 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 outsmart themselves when developing their relative sizing scales. Effective Agile teams must develop a simple, repeatable scale for feature-level sizing and story point estimating.
Ensuring successful release delivery
There are many reasons why the feature and story sizing scale developed by an Agile team is so important to successful release delivery. The estimating scale touches every part of the release as well as each sprint. Given its importance, it is valuable to review specific reasons why Agile teams need to develop and refine a workable story point estimating scale:
- For rapid high-level sizing of features to enable 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 for 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 working 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 iterative re-estimating
Get the most value from Agile practices
For Agile to work effectively and deliver rapid value realization as expected, teams must be able to estimate quickly and simply. They must also be 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 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.
For those new to Agile
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 before finalizing the sprint. It gives the team an opportunity to see how the story point scale aligns with the hours and ensure practically that those hours are available in the upcoming sprint.
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.
If you’re ready to further enhance your knowledge of Agile, we encourage you to enroll in the Master’s Certificate in Project Management.
About the Instructor: Shawn Belling
Shawn is a Senior Consultant with Farwell Project Advisors LLC and adjunct faculty with UW–Madison and UW-Platteville. Prior to joining Farwell in July 2017, Shawn was VP -Development and Support, and VP – Professional Services for CloudCraze Commerce (enterprise eCommerce software built on Salesforce). Shawn brings 25 years of project and program management experience to his passion for teaching, research and consulting for businesses, universities and professional organizations.