It is well-known that Sprint Planning is one of the most valuable events in the Agile world. It is a ceremony that drives the team’s work and shows directions; it is the best moment for the team to clarify what has to be implemented and predict what will be.
During Spring Planning the team makes its estimations based on 4 criteria:
- Dimension of work
- Complexity
- Knowledge
- Overall uncertainty
Well, add one more, speaking by experience: Risk!
It is a wonderful opportunity for people to challenge each other and, even if they don’t really recognize it, they share knowledge! A good Planning always leads to good outcomes and desired results.
It may feel as being a hostage, but nobody leaves the room unless everything is clear and figured out. My beloved code gigs are always eager to start coding. But hey; how can you start coding if you don’t know what to do and what the target is!
So, let’s see some common mistakes that people make during Sprint Planning and consequently, should be avoided:
- Sprint Goal is set afterwards, or no Sprint Goal is set at all
Wow! How can you possibly start working on anything if you don’t have a goal!? You will be lost, and your plan will fail. ☹
Sprint Goal empowers team to make the right decisions and sets the objectives! Having a Goal does not mean that you lose your freedom; it promotes team spirit and it helps on staying focused.
The first thing that the POs should do once they pop-in, is to set the Sprint Goal and work together with the Agile team to finalize it.
- Focus too much on velocity
Voltaire, the French writer, said, “The best is the enemy of the good”. A wise statement that is often used on our daily routine. This is what we want to achieve in Agile but don’t feel the urge to maximize the team’s velocity on each Sprint. If a team can consume 100 SPs, don’t push to do 200 SPs! Let them target for 120 SPs. Don’t push for running faster, the team will lose focus and flexibility. Over-committing might make things worse, there is a high risk of compromising quality, causing quantity prevails and not leaving room for handling unexpected events. Add more only when necessary and if times allows, but don’t push for promises that will lead to fake.
- QA does not vote
Oh no! Why? QA/Tester is also part of the Agile team. Everyone votes, we are one team with all capabilities inclusive. No exclusions, no excuses (you can listen to the song! ?)
- No acceptance criteria listed on User Stories
Acceptance criteria define the success of a User Story; they add details on necessary features and functions, drive development and help preventing waste. Having no acceptance criteria means that the User Story is ‘naked’, the PO cannot decide whether a User Story is really done and the team does not feel confident about the commitment they are making.
- Changes not allowed during the Sprint
That’s an interesting topic. Agile welcomes changes and promotes flexibility. Changes should be linked to the Goal. Team is encouraged to allow changes regardless of where they are coming from, simply because they want to meet the Sprint Goal. The team can add and/or remove something and adjust the backlog.
- Not planning the unexpected
Here comes the Risk Management that teams are lacking. Complex projects require risk management. The selection of the correct approach plays an important role as complexity degree differs. The most common way to deal with the unexpected is to use buffers; this doesn’t always work out because it is rather possible that you will use the buffer to cover delays. Scrum framework clearly mentions the potentially shippable increment, therefore, mitigate the risk by shipping early and often.
- Ignoring the ‘Definition of Ready’ (DoR)
This is how backlogs are getting unprepared and Sprint Planning event takes ages. Preparation matters, that’s why the DoR is for. It defines when items are actionable and can be ‘loaded’ into the sprint. DoR prevents wasting time and effort and protects the team from starting to work on something that has no value, it is unclear, and it is likely to cause impediments. Strong advice: do not skip it, it truly helps!
Conclusion: Planning is not easy. No one can predict the future unless he/she has a magic ball. No need to get crazy, though. One of the Agile gurus mentioned that “Agile hates plans but loves planning”. Here you are!
Author: Rania Alexiou.