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.
FAQ’s
Q: What is agile estimation?
A: Agile estimation is the process of estimating the size or effort required to complete a feature or user story in agile software development.
Q: Why is the feature and story sizing scale important for agile teams?
A: The feature and story sizing scale is important for agile teams because it helps with rapid high-level sizing of features, release, and sprint capacity planning, prioritization decisions, and strategic decision-making, and enables teams to rapidly and iteratively estimate and commit to working within their sprints.
Q: What is a T-shirt sizing approach?
A: A T-shirt sizing approach is a comparative sizing method used by agile teams to size their work. This approach uses XS, S, M, L, and XL to estimate the size or effort required to complete a feature or user story.
Q: Why do experience agile practitioners recommend a less granular estimating scale?
A: Experienced agile practitioners recommend a less granular estimating scale because a more granular scale implies a level of precision and certainty that is not realistic nor necessary when sizing features and stories.
Q: Why is it important to convert T-shirt sizing to a numeric scale?
A: It is important to convert T-shirt sizing to a numeric scale with the help of an experienced scrum master or coach to help teams establish a common understanding of what each size represents and enable them to track progress over time.
Q: When are estimates of effort in hours appropriate?
A: Estimates of effort in hours are appropriate when teams break their committed stories into smaller tasks in the final steps of sprint planning.
Q: Can the story point scale be converted to hours or other metrics for project sponsors or product owners?
A: The story point scale can be converted to hours or some other metric for project sponsors or product owners, but it is important for them to understand that the sizing scale is first and foremost for the use and benefit of the agile team, and that their conversions should not be used to second-guess the team’s estimates and progress.
Q: How can effective sizing and prioritization help agile organizations?
A: Effective sizing and prioritization can help agile organizations consistently improve and realize rapid value creation.
Similar Content:
-
Comparing agile frameworks
-
Agile release planning: 7 Steps for new teams
-
5 Key elements of an agile user story
