Have you ever looked at that giant list of work and items in your product backlog and thought: Now what? There’s a ton of work to do on your project. How do you decide which user stories go from your product backlog to your sprint backlog? The answer may be in only three simple questions.
Below you can find three questions to ask yourself to know which stories should be part of your next sprint.
But First: Free Stuff!
Before we get to the questions, an important part of any Scrum sprint is an effective sprint template. Ensure you have an effective template to manage your work. The template should also keep stakeholders in the loop with easy reporting.
TOOL: If you need help getting started download the free sprint backglog template!
The template below integrates and works well with my other free product backlog template. Download away!
Scrum: High Value Quickly
When asking the three questions below it’s important to keep a few things in mind:
- You want to select user stories that deliver high value for low effort
- You want to select the proper ratio of user story types:
- Bugs
- Features
- Technical Work
- Knowledge Acquisition
On to the questions!
Sprint Backlog Question 1: Is the User Story In Line with Your Velocity?
Staying true to your velocity is one of the most important elements of Scrum. Don’t add so many story points you exceed your team’s velocity. Don’t bite off more than you can chew. You need to draw a line between:
- Increasing your team’s velocity a bit in the name of incremental improvements. And…
- Un-realistic velocity levels that will only lead to team discouragement.
Learn How to Run Your Best Sprint Planning Meeting Ever
Also, stay true to the story point measurement. Don’t get yourself and your team in the habit of thinking of user story effort in hours. There’s a reason Scrum recommends using story points and velocity. Story points have been shown to be more accurate than hours. They account for unknown variables in a project, such as team availability, team member capability etc… Always stick to story points and velocity.
Story points account for unknown variables in a project, such as team availability, team member capability etc…
Sprint Backlog Question 2: Are Sprint User Stories Sufficiently Decomposed?
Does the user story have a story point value of 8 or less? This is a good rule of thumb when deciding to include a user story in your sprint. You should be using the Fibonacci Sequence to estimate your user stories. Estimate the effort of each story by assigning them a number on the scale:
1, 2, 3, 5, 8, 13, 21, 34, 55 etc…
A good rule of thumb for deciding if user stories are sufficiently decomposed is evaluating their story point value:
- Story value 1 – 8: Ready for a sprint
- Story value 13 -34: Epic or release stories – need to be broken down further.
- Story value 55 and up: Feature roadmap stories – need to be broken down further.
When some stories first arrive on your product backlog they may have a high number assigned. These stories need to be whittled down to smaller story point values. To do this either:
- Divide a single story into multiple stories, or
- Better define the story to a more accurate, and lower estimate
To do this it is vital that your team is spending at least 10% of your time on product backlog grooming.
Read my post on Product Backlog
Putting user stories in your sprint backlog with a low story point value will ensure that your team can always deliver some value during a sprint. Delivering value early is one of the principal objectives of Agile. When beginning a sprint always swarm the user story with the lowest story point value first. Completing at least one story early will fuel your team’s motivation and efficiency.
Sprint Backlog Question 3: Does the User Story = Sprint Goal?
Every good sprint should have a sprint goal or objective. Every single user story doesn’t have to fall under this goal but the majority should. Doing so will help the Scrum team focus the work and cooperate around a common result.
Completing at least one story early will fuel your team’s motivation and efficiency.
Your sprint goal itself should be effective. The goal should be:
- Valuable and meaningful
- Measurable
- Specific – not too big or ambiguous
- Visible – put it somewhere where everyone can see it
Asking these three questions will take your next sprint up a notch.
As with all things, you should remain Agile and adaptable. Take the questions above and iterate with your team, discuss ways to adapt this blueprint and improve. I’d love to hear what other questions or tips you have on sprint backlog planning. Leave me a comment below!