An Easy Way to Estimate Agile Scrum Story Size for Your First Sprint
Your team is new to estimating Agile Scrum Story Size. You planned for your first release as discussed in Why Your Scrum Team Needs a Release Plan. Your Product Owner wrote Stories that meet the criteria described in Write Better Stories and Why Every Story should have Acceptance Criteria. You have candidate Stories for your first Sprint Backlog.
You are ready for your first Story Grooming Session.
Two activities occur at Story Grooming:
- Review Stories for clarity, to ensure everyone understands the requirement.
- Assign a relative Size to each Story, so your team can begin tracking Velocity.
Your team should be able to decide whether or not the Story makes sense. However, deciding relative Story Size often causes consternation for new teams. Most teams are happy to move away from estimating work in hours. But, when you are new to the concept of relative sizing, it’s hard to know where to start.
Some are taught to use tee shirt sizing: Small, Medium, Large and Extra Large. But, that doesn’t quite help assign a numbered-size, does it?
Many are taught to assign Story Points based on the Fibonacci Sequence: 1, 2, 3, 5, 8, 13, 21 … We are taught that each number in the sequence represents twice the level of effort as the previous number. But, that doesn’t really help either.
In Agile Scrum, we learn that accepted Stories must be validated as ready to move to Production. Therefore, the level of effort for each Story must take into account the complete development lifecycle, from design to spec to code to code review to quality assurance testing.
Start with the Development Lifecycle
At GSD Mindset, we teach newbies to initially size Stories using the Fibonacci Sequence based on their gut feel for the level of effort required to complete development lifecycle aspect of each Story.
We recommend the following guidelines to help new teams get started:
Size the Story based on the effort it takes for 1 Developer and Tester to complete it.
For a two-week Sprint:
If the team thinks the Story takes 1-2 days of effort, assign 1 or 2 Story Points
If the team thinks the Story takes about a half week of effort, assign 3 Story Points
If the team thinks the Story takes about a week of effort, assign 5 Story Points
If the team thinks the Story could take the entire Sprint, assign 8 Story Points
If a story is larger than 8 Story Points, divide it into multiple Stories. We do not recommend bringing a Story larger than 8 Story Points into your two-week Sprint.
Use an easy method for group estimating like Planning Poker to reach consensus.
When discussing individual estimates, always question extreme high and low estimates. We all know that some requirements are quick to code, but complicated to test. If the team has trouble deciding, error on the side of caution, especially for your first Sprint.
If the Story is not well understood or cannot be sized, 3 things should happen:
- Update the Story and Acceptance Criteria to be clear
- Break down large Stories greater than 8 Story Points into smaller Stories
- Place vague Stories back into the Backlog for refinement
How Many Story Points for Your First Sprint?
If our initial sizing method dictates that it takes a Developer and Tester an entire two-week Sprint to complete an 8-Point Story, we recommend the team bring in 8 Story Points per Developer. For example, if the team has 1 Tech Lead (who doesn’t code), 4 Developers, 2 Quality Assurance Testers and 1 Business Systems Analyst, bring in 32 Story Points.
Then Develop Your Own Method of Story Point Estimates
After one or two Sprints, review the accuracy of your Story sizes (you’ll only be right half the time) and use the Stories the team feels accurately represent a 1, 2, 3, 5 and 8 as examples during Story Grooming going forward.
Don’t overthink it.
And please, please, please don’t estimate in hours.
I’d be interested to learn how your team got started.
Cynthia Kahn
CynthiaK@gsd.guru 503.799.5500
My teams have been using this method to size stories using a tool called Osteka. As a Scrum Master, this has been an effect way to get them started and especially helpful to newbies. The scrum teams become very cohesive in sizing stories, much faster than with other methods I have tried in the past.
Thanks for sharing Linda. I’ll check it out.