Zuzana Gočová
Scrum Master, ERNI Slovakia
Joffrey Zehnder
Principal Consultant, ERNI Switzerland
What planning is about
Planning is the first of the Scrum ceremonies and takes place at the beginning of the sprint. The Scrum team plans the work for the upcoming sprint. The planning has to answer two questions: “What can we deliver in this sprint?” and “Which user stories will we choose to get done?” The basis for this meeting is the product backlog, which the Product Owner prioritises. The result of this meeting is the sprint backlog, consisting of ready Stories that the team can work on during the sprint. The aim of the planning is also to define the goal of the sprint. Present for the planning are the Product Owner, the Scrum Master, who facilitates the meeting, and the whole team of developers (which includes testers and every other role the team consists of).
Factors critical for smooth running
PO preparation and prioritisation
It is important that the PO does the prioritisation of stories in advance, and not during the planning. This means that when we start with the planning, the backlog is already prioritised. It may happen that there are changes during the planning, but the initial priorities should be set.
It is good practice to add story points to a story already during the backlog refinement. If story points are missing, then this is the latest point in time to discuss the story and add story points.
The Scrum Master as a timekeeper
Much of the smooth running depends on the Scrum Master and how they facilitate keeping the timing, ensuring that the planning does not exceed the given time limit and that the discussions stick to the topic.
If the team does a technical deep dive, the Scrum Master has to bring them back to the figurative surface. It is advisable to ask if it is necessary to discuss the technical details in that much depth. The team should be clear on the matter enough to have a good feeling of how they want to achieve the story, but not every little detail needs to be clarified; this can still be done during the sprint.
Time scope
We try to limit the planning to 2 hours, but strictly following the Scrum guide, there is Planning 1 and Planning 2. We aren’t so strict, but pragmatic, and usually just need Planning 1. Please remember that the team sees and discusses the stories at least once already during refinement.
Planning 1 takes around 2 hours for a two-week sprint. The PO walks the team through the prioritised backlog. They explains every story with the latest changes. Then in Planning 2, the team has an in-depth technical discussion. As already said, in our experience, we always have just the Planning 1, but sometimes the team has another meeting as follow-up where they break the stories into subtasks. It is not always needed, but if required, we do it to help the team.
Soft skills
In the Planning, as in every Scrum event, team members are challenged to share their opinion through open communication. Here, trust within the team is needed. Constructive discussion might lead to knowledge sharing and even to a better solution than the first proposal.
The whole team does the estimation
The story estimation is done with the help of Planning Poker Cards (good electronic alternatives also exist if you work with a remote team). All team members should estimate: developers, testers and operations. And yes, the PO as well. Even if someone doesn’t have the knowledge of how things work in the development, after a few sprints they’ll start to get a gut feeling as to how the team sizes stories.
One thing the Scrum Master prepares in advance is the velocity. The forecast of the velocity is needed so that the team knows how many story points they are able to deliver during a sprint. This helps the team to not overcommit themselves and therefore they should be able to deliver what they committed to.
Common pitfalls
Overcommitting of the team
Based on a false idea about the velocity, it may happen that the team commits to too many stories. This means the team is not able to deliver them within the sprint. This disappoints the stakeholders. Also, the opposite case often happens. This leads to a situation where the team has finished the tasks within a week. Of course, further tasks can be taken in additionally. However, it is a clear indication that poor management has taken place.
A countermeasure is the calculation of the velocity and good estimation practices (see above).
A very demanding PO
It is not rare for a PO to be very demanding, having the idea that something should not take that much time to deliver. It may happen that they talk the team into what stories to take and how much time to dedicate to them. Once it doesn’t work out, the PO and the team will then be disappointed for not having completed the sprint goals.
It’s bad practice to tell a team how long something should take to develop. Team members are specialists and know more about solving the problem at hand than anyone else. Having said that, it’s OK for a PO to challenge the team in its estimations. But in the end, the PO needs to respect the team’s decision about a story’s size, whether they like it or not.
The team take stories into the sprint that are not clear enough
This raises risks that the story will not be finished as something may pop up that the team was not counting on. The story needs to be understood by the majority of the team.
Already showing and discussing a story in the refinement stage is a powerful mitigation to that pitfall.
Overly complex stories
(For this example, we assume that a story estimated 1 story point can be done within 1 day. You may need to adapt the numbers below to your current situation.)
If you have a complex story estimated very high, e.g. an 8, it is good to challenge the team and convince them to split it into less complex parts.
In our experience, stories taken into a sprint should range between 1 and 3 SP; in exceptional cases, a 5 when a story really, really cannot be split. An 8 is not acceptable as it means one developer is occupied with it for the entire two weeks of the sprint.
Best Practice Tips
To sum up the entire episode into some of the most important points:
- Split huge stories into smaller stories
- Have a refined, prioritised backlog
- See a story at least 3 times before taking it into the planning
- Give the team enough time to look through the backlog
- Keep dependencies in mind during planning between teams and between stories