How to Have Efficient Sprint Planning Meetings
How to Have Efficient Sprint Planning Meetings
Join the DZone community and get the full member experience.Join For Free
See why over 50,000 companies trust Jira Software to plan, track, release, and report great software faster than ever before. Try the #1 software development tool used by agile teams.
Too many of us have been burnt by this. There we are again. Getting together every other Monday, usually devoid of a clear agenda, trying to “plan” a sprint. We start OK. But before you know it, we are all over the place. We argue in a civilized manner on how this story is not clear, or that the story needs to be discussed a lot more for it to be even estimated. Confusion creeps in. Soon the engineers take over “planning” part of the meeting and morph it into a “clarification” frenzy. The Product Owner (PO) is overwhelmed as technical terms are thrown in the air and on-the-fly technical solutions are spit-balled. Sadly, sometimes legitimate good solutions get lost in translation and noise. The Scrum Master or team lead brings things under control, but there is lost time.
Then we bandage this process by following up with emails throwing in definitions of “Sprint Planning”. The Scrum Master sends out his/her emails on how the process is supposed to be. The next couple of meetings are acceptable but we soon relapse as a team and go back to our old habits. The root cause has still not been addressed.
Often, the main problem is that some engineers are not confident about taking on a story until they have talked through it “technically”. Doing so gives them an idea whether they will slug it out or sail through the work planned. And no one wants to slug it out! Some engineers would rather do it while sitting in their bullpen, yet others would like a discussion/debate around it because they would rather go with a team consensus. Sprint Planning is way too critical a meeting to be used for this. But it keeps happening because the team is not organized.
In the end, the lost productivity is unfortunate and costly. But the problem is not that complex and can be solved by a small tweak. Rather than misusing the planning meeting, focusing on definitions or “supposed-to-be”s or process reminders, how about preparing for its success by setting up the stage for this meeting? What if the planning meeting, in the strictest sense was only about... planning!! Stories are ready, tasks are cut out, story points are estimated. All we do is finalize on the Definition of Done by having a deployment as one of the goals. Kapish! Think about it! Even doing that efficiently sprint to sprint, requires discipline and focus. It becomes even more challenging when agile teams are sized abnormally.
So again, how do we practically get there? Well, what has worked for me in the past to a good extent is to have "Grooming Huddles". Remember, the grooming that POs are supposed to do? Well, make it a mini-summit and developer focused. We start with what POs have prioritized. Then we look at well-defined specs and mock ups of the stories in that order and see if anything is missing. And no; not all questions have to be answered in this meeting. High-level steps that usually do the job are:
- Take a pass at a user story.
- Read through the mockups and specifications.
- Deliberately throw out questions on 4 levels:
- Front-end work (FE)
- Back-end work (BE)
Dependencies and unknowns usually surface when you talk about the work to do, i.e. FE and BE. And it is perfectly OK to have dependencies and unknowns. I actually get nervous when I do not see them on non-trivial stories. Having them is a signal that we have thought out the work well enough, if not perfectly.
So now this has now become a developer’s meeting. They will now start owning it and looking forward to it. And the exit criteria of meeting have to be well thought out stories, from high-mid level implementation point of view that all engineers are comfortable with. But discussing pseudocode or super fine development details will be overkill. From another perspective, think of this as an extension of Planning Poker sessions. Too many engineers resist it in its purest form without telescoping into development details. So why not actually delve into development details.
Let us do a dry run of this. Say you have a screen that encompasses a feature. The screen has two tabs. Each tab is a story in itself, of course, but in each story tasks are agreed to as the following as high level tasks:
- Implement REST API for Tab A
- Implement HTML and Styling for Tab A
- Implement Angular module, controllers, services etc.
As soon as you think this is going to be easy, a developer complicates things by mentioning that we have to use the style sheets supplied by our UX folks as per the Human Interaction Guidelines. Well, it turns out that this is the first time this is being done! So that right there is a dependency AND an unknown, thus having a bearing on estimates. But as a team we are equipped to deal with these. I have noticed that as developers, over time, we get tuned to each other and estimate the scope well when we do these grooming meetings as a team. Statements like “yeah I can help you with that”, “let us talk to that other team, they did it last month" or “I can put you in touch with John to get you access”, are signs that we are pushing through as a unit and minimizing the risks of dependencies and unknowns.
So coming into planning meetings now, we have discussed stories that are not big question marks which often make developers nervous and give them an excuse to call these stories “ambiguous”. Having hourly estimates is a bonus when starting the planning. But days estimates should be the goal. Overtime, I have also noticed that grooming meetings consistently end with all stories estimated. All that is left to do now is to create a sprint and target the stories that add a meaningful feature set. Sprint planning ends in 30 minutes!
I believe this approach can compliment all agile methodologies that have the elements of time boxing and planning. Ultimately the team has to be conscious of the fact they own the process. It is there to serve them and make agile development more disciplined.
Opinions expressed by DZone contributors are their own.