Planning meetings is one of the essential Scrum ceremonies that allows to prioritise tasks, avoid unexpected failures and deliver better code more efficiently. However, with time the repetitive meetings might turn into routine and stop being that productive.
If this sounds like your case and your planning meetings need resuscitation, this blog post is for you. Below you can find typical bottlenecks and ideas on how to revive your planning spirit.
First things first – is your Product Backlog well refined?
If there is always a bunch of unexpected work that floats to the surface after planning meetings, the problem could lay not in the planning, rather in the refinement process.
During refinement, the team (and not the Product Owner alone!) is supposed to add details, estimates, identify dependencies, and order the items in the Product Backlog. It’s not only about revising the Backlog but also studying the items and how much effort they might take, so there is an idea of what can be done in a Sprint. Utilizing tools like a daily planner can streamline this process, ensuring that tasks are clearly defined and organized, thereby enhancing the efficiency of the refinement phase.
A well-defined Product Backlog serves as a basis for a smooth and efficient planning meeting. And the other way around: if the team hasn’t spent enough time on refining the Backlog, most probably they will need to come back to it during the planning meeting (to the detriment of planning obviously) or eventually experience unexpected bulks of work in the Sprint. So unless you “enjoy” 8-hours-long planning meetings and surprises during the Sprint – do your homework refine your Backlog well.
Always start with “Why”
There is a strong tendency to keep the conversation highly technical when talking to the development team. This is a dangerous practice that leads to developers’ detachment and consequently motivation decline.
Instead of keeping it dry and technical, use planning to explain a vision for the product (or its part), why it’s needed, what effect on users or a company it will have. Provide a broader picture and set up one big goal for this Sprint, explain its unambiguous aftereffect and place on a global roadmap.
A clear understanding of what needs to be done and why leads to more meaningful discussions during the planning and higher involvement of the team.
Give your team the wheel
We know, it’s hard to balance business needs with quality software development. The former wants a new feature to be released yesterday, whereas the latter requires one month to do that. However, for the successful and sustainable development process, it’s the development team that should determine their capacity.
It’s naive to expect good performance in a long-term from developers who are pressured while deciding what can be “done” in a Sprint and have no control over what needs to be accomplished. It will only speed up the avalanche of accumulated technical debt, which will slow down the development even more and grant the team a perfect excuse for delays and overestimating: “with such tech debt, it cannot be done faster”. Besides, it’s emotionally exhausting to work in such conditions and fraught with not only failed Sprints but also burnouts.
Avoid the fear of failing
While committing to certain tasks the team takes risks, as in some cases it’s impossible to predict smooth and bug-free development and working process. Without a healthy failing culture (when failures are despised, there is no shared responsibility), the team might delay working on complex risky tasks and hazard the Sprint performance.
The planning meeting is a great occasion to work on this problem. Communicate the uncertainties that the developers have and the risks that need to be taken to all the stakeholders. Reserve a buffer time to fix potential problems. Work together on complex issues. In other words – make it safe to fail, so that the team members aren’t afraid of taking the leap.
When traditional agile practices don’t work – try something new!
If the team stuck with planning, it seems to be overwhelming for people and doesn’t bring the expected result – think of trying something unconventional instead of continuing to bang your head against the Agile Manifesto or Scrum guidelines. We know, it sounds like apostatic advice, but isn’t it in nature of agile to put individuals and interactions over processes and tools?
You’ve probably heard of #NoEstimate movement that gets its momentum now (if not here is what you need to know about it). In a nutshell, the founders of this movement say that correct estimates are rare and that teams can work effectively without estimates (this book promises to explain how to do that).
Honestly speaking, we are not convinced that this approach is a cure-all, although it makes a lot of sense when planning at a bigger scale or in a complex environment. And as many teams claim #NoEstimates work for them, it may be an alternative path to follow when traditional planning practices stop working or when the team needs a way out of “it is agile so it’ll be ready when it’s ready” trap.
* * *
We hope you enjoyed your read. If you’re eager to learn more about Scrum and Agile, go and check our previous blog posts related to this topic:
