Sprint planning doesn’t have to be hard work. This ceremony takes place at the start of the sprint and allows the dev team and product owner to work together to agree and understand what items will form the sprint backlog for the upcoming sprint.
When we started out on our Scrum journey, sprint planning was always painful. With the added difficulty of being a distributed team, we often have to hold this meeting over videoconference with screen sharing. With half of the team inevitably being in an early-morning, pre-caffeine stupor and the others with rumbling stomachs at their lunchtime, sprint planning had the potential to run for hours. This left the team exhausted and sluggish, and it got the sprint off to a slow start, as well as leading us to write sloppy sprint goals due to everyone’s eagerness to get the meeting finished.
We soon learned that the key to good sprint planning was in a good product backlog refinement process.
Product backlog refinement, sometimes known as product backlog grooming, is not a defined ceremony within the Scrum framework. Instead, it is detailed as an activity, and Scrum teams are encouraged to commit approximately 10 percent of their sprint time in carrying out this activity.
The product backlog, the "wish list" of future product features, is the responsibility of the product owner to manage (with the ScrumMaster to help if necessary). Product backlog refinement sessions allow the PO to collaborate with the team to communicate ideas and work ensure that the vision is being translated into satisfactory user stories with clearly defined tasks.
There is no set structure for the product backlog refinement sessions, and it is down to each Product Owner and dev team to work out what suits them best. On my current team we have defined a process that works well for us, and this is what I want to share with you today.
- Write user stories and define subtasks.
- Define acceptance criteria for the story.
- Estimate the tasks.
- Check against the definition of ready.
- We start by writing our user stories. This is led by the product owner, who will outline the user journey or feature that he wants to include. As a team, we create the user story following the standard "As a (user) I want to (some action) so that (some outcome)" formula. Following this, we start to examine the user journey and break it down into actionable subtasks. On our team we use Jira Agile, so the user stories and subtasks are written up in Jira and added to the product backlog.
- Once we have an agreed user story and a list of defined subtasks, we look at the acceptance criteria for the story. The acceptance criteria forms our checklist to ensure that, as a dev team, we understand the PO's expectation and what the user story's outcome and aim are. Acceptance criteria cover both functional and nonfunctional requirements and should be measurable, unambiguous, and testable. By assigning acceptance criteria to a story, we are able to ensure that the story is tested and working as expected.
- We use story points to estimate through planning poker -- physical cards used during colocated sessions and virtual cards during distributed sessions. We currently do our estimation during the sprint planning meetings, but now that we are an established team and understand our velocity, we are making the move to estimating high-priority items during product backlog refinement sessions when we have the opportunity to do so. We will only estimate in sessions at which the entire dev team is able to attend.
- Finally, we check our story against our team’s agreed Definition of Ready. The Definition of Ready is a team document; an agreement between the dev team and the product owner of what is needed from a story to allow it to be brought into a sprint backlog. This is a single checklist that covers all stories; similar to acceptance criteria, a DoR should be measurable and clear. This is something we were not good at doing in our early sprints. We duly wrote a DoR as we knew a good Scrum team should, and then we were so overwhelmed by the transition to the Scrum process that we forgot to look at it again. We revisited our Definition of Ready, refined it, and now ensure that a story has all its prerequisites. Once the story meets the DoR, the dev team effectively confirms to the product owner that the story is "sprint-ready" and can be added to the next sprint backlog if its priority allows this.
By refining your refinement process, you should be able to effectively manage your product backlog and streamline your sprint planning meetings, leaving your Scrum team more energized and ready to start the sprint.