In Agile methodologies, one of the most important meetings along with the daily standup and the retrospective is the sprint planning. Its objective: getting a shared understanding of what there is to be done for the time of the sprint, and how to do it. The functionalities that are supposed to be developed are defined in “user stories”, a simple sentence that describes it including 3 elements: who? what? Why? It looks like this: “As a customer, I want to add an item to my shopping cart so that I can buy it.”
Many Agile teams dread this moment, as they find it difficult to divide up the work into well-defined stories that are achievable during the sprint. But with some advice and a little practice, you’ll soon find it as easy as pie!
Before the sprint planning
Before the sprint planning begins, the product owner has to prepare the user stories that will be addressed during the sprint. This preparation work will be decisive to the success of the meeting. To make sure your user stories are well defined, you can use the acronym INVEST.
- I for Independent – from any other success story
- N for Negotiable – it isn’t constrained by a specific contract for features
- V for Valuable – it brings value to the user
- E for Estimable – it can be assessed to a good approximation
- S for Small – it can be carried out in few person-weeks, or even person-days
- T for Testable – at least in principle
Therefore, a good user story should be independent, negotiable, valuable, estimable, small and testable.
The sprint planning only happens once during the sprint, but some product owners like to set up an intermediary meeting in the middle, called “backlog refinement”. This 30 to 60-minute meeting helps to prepare the next sprint planning by improving the user stories and making them more “INVEST”.
During the sprint planning
The sprint planning cannot be too long to keep everyone engaged – 1 hour is best, 2 hours is a maximum. The product owner defines a common goal – for instance, improving the reporting. And inside this goal, team members assess the complexity of each task that composes the user story.
The complexity assessment is a great way to estimate the time to spend on a task, thus overall on the story. It helps to make sure you don’t overcharge your sprint or the opposite – but the opposite rarely happens. Each team member is asked to participate in the “planning poker” and allocate a level of complexity for every task, using the Fibonacci suite: 1, 2, 3, 5, 8, 13…
In this exercise, the most important isn’t just the number of points you get, but the discussion around that helps everyone understand clearly what needs to be done.
Want To Improve Your Agile Retrospectives?
Download our free Retrospective Outcomes Canvas
Get our free retro canvasPitfalls of the sprint planning
Preparing the sprint planning can be more difficult than it seems. Two usual traps are :
- planning too many user stories for the sprint – it will just force your team to work overtime and damp their spirit ;
- not detailing enough the benefits for the user – the more detailed, the easier it is for the team to grasp the aim of the feature, and maybe to suggest a better solution.
However well prepared the sprint planning may be, discussions around the complexity assessment can easily veer off track when people disagree. Be careful not to let the discussion move on to technical details or endless arguing about complexity levels. The time spent on a user story shouldn’t exceed 10 minutes or so. Make sure that everyone participates. The animation of the sprint planning relies on the scrum master – he/she has to make sure that the most “mouthy” team members don’t hog the debate.
If you apply these pieces of advice, I can assure you your sprint planning will run more smoothly. Let us know how the next one goes in the comment section below!