Sizing Challenges

If you are a coach, scrum master or team having trouble with sizing your user stories and consequently estimation of effort and collaboration in story points (volume, knowledge, complexity, uncertainty, dependencies, risk) try out the triangulation technique. This technique also works for no-estimate teams operating in non-enterprise environments. Additionally, teams that experience significant changes in velocity from iteration to iteration or story point inflation may need to use this calibration technique.

How-to

Step1. Draw out the circles and lines on a marker board, easel paper, or other medium. Leave enough space to stick your stories within or adjacent to the circles.

Step2. If the team hasn’t calibrated on a “1” or “small” sized story have them perform that exercise first. Have a short conversation about at least three reasons the team believes this story is a “1” or “small” sized story. Document the reasons.

Step3. The team should then choose a large story (13, 20, 40 on a modified fibonacci sequence), or a “2X on a t-shirt sized team.” Have a short conversation about at least three reasons the team believes this story is a “13 or 20” or “large” sized story. If the story winds up being an epic, choose another story. Document the reasons.

Step4. The first two stories should be likely candidate stories that will remain in the product backlog and not be worked during the experiment iteration / sprint.

Step5. At the end of the iteration / sprint the team chooses any done done story that was sized to fit within the boundary of the two input stories as the test.

Step6. Facilitate team discussion about why the test story is correctly sized by asking “How well did we estimate this story?” Document the discussion points around the triangulation on stickies.

Step7. Have the team organize the discussion points relative to the test story and the high or low story as justifications for a higher or lower estimate.

Step8. The team should analyze the results and root cause the justifications for whether or not the test story was an accurate estimate, or not.

Step9. The team should create improvement stories designed to change the estimation thought process and collaboration to increase the accuracy of the estimates for the long-lived team.

Notes:

• Not a useful technique for teams that are not long-lived
• The high-low boundary stories should be estimates that are still in the product backlog.
• You can alternatively run the experiment with high-low done done stories.