6 Techniques for Efficient Agile Planning Meetings
There is no shortage of articles on how to run a great planning meeting for agile teams. And yet, they remain a challenge for many successful teams! The primary goal of a planning meeting is to build collective understanding: a great session will help set the context for the team about the problems they are trying to solve in the short term, and allow the time and space to explore stories or solutions. As the meeting is time-bound, the goal will not be to get to every last detail — these specifics can come throughout the iteration or sprint. However, here the team should ask questions and drive toward just enough information to be in alignment about the time ahead.
Here are 6 tips for a great planning meeting:
- Make it time-bound and regular
A great planning meeting is time-bound: my recommendation is an hour each week (though this could vary a bit based on your team size or your iteration or sprint length). It is quite challenging for a team to spend more than an hour discussing stories or work — it can be exhausting and you can go down rabbit holes! If you commit to an hour, and you make it regular, these meetings can go from feeling like a slog or a big deal, to a well oiled machine that drives towards alignment each week. If you find that you need more time, this could be a good indication to investigate if you’ve gone into too much detail in the meeting, if you need to implement a parking lot, or perhaps even that the team is too big! You can use this as an indicator.
2. Have the right people in the room
When you’re discussing your goals or what you’ll be focusing on next, it is important to have the right people in the room. Many agile teams bring product managers and engineers when planning — this is great! If you work with a product designer, they should be there too. Consider if there are other people on your team who are critical to a certain feature’s success — rather than showing them a feature after it is done, when the cost of change is high, might you bring them in to the conversation earlier? I have seen some teams bring their QA team members or even compliance or security team members in for some planning meetings: by making them part of this discussion around prioritization, the “why” and the “how” — it can mean you have discussions earlier rather than throwing it over the wall to them later. Of course, you will want to balance this with making sure you keep the meeting relatively lean and efficient.
3. Let product and design cover the why, let engineers discuss the how
It can be tempting to come with an entire backlog of work, perfectly planned and detailed out for an engineering team. Don’t do this! Product and design should cover the why of what you’re building and set the context. They will help your team understand what users need, what problem you’re trying to solve, and some high level explanation of what the solution might be. While they may describe the solution from a user’s perspective, the engineers should take the lead on the “how” and the technical implementation details. Product and design may have opinions — and that’s great — but when you bring in a wider set of perspectives to the conversation you’ll drive better results.
4. Review one backlog, stack-ranked
Not all backlogs are created equal. Many teams keep a very loose definition of a backlog — some set of stories or tasks, all in a single sprint definition. I recommend you go further than that and ensure that the list of items is stack ranked, in a single priority order. While it can be challenging to get to that one priority, it will remove ambiguity for the team. Before the planning meeting, the product manager should work to prioritize and consider the order in which the team will tackle the work, based on user value. When you get to the planning meeting, the team should discuss that priority — understand why they are valued in that way, and debate if there are ways to add more value to the users sooner.
5. Estimate based on complexity
This one is often controversial, but I would argue there is no other way (sorry points = hours people). You should estimate in your planning meeting based on complexity. The product manager should reach each story and explain the why or background, as well as the relative priority. The engineering team should then discuss the implementation details for a few minutes, calling out any potential gotchas or areas that could uncover more complexity. When the team is ready to estimate, each one will put their thumb up to indicate their readiness. On the count of three, each engineer will hold up the points values on their fingers. The team should then discuss the differences — the person who ranked the highest should give their thoughts, the person who gave the lowest theirs. This will help spark debate and suss out the implementation even more. By voting at the same time, it will help those quieter team members to have a voice and opinion. Once you’re done debating the different approaches, vote again to see if you have more shared understanding on the path forward.
6. Be as prepared as you need, based on the team dynamic
When a team is newly formed or there are many new team members, you may not yet have found that new team’s rhythm. During these times, it is often helpful to invest more time in discussing details or driving towards alignment and clarity. You may find that you need to come more prepared and you may even do lightweight pre-planning meetings. However, as some teams get more familiar with each other and the problems they are trying to solve, they may need less time in planning meetings to go over context. Consider your team and where you’re at — do you have some new team members? Have engineers recently sat in on user interviews and have a ton of context about what you’re building? Are you starting a new track of work for a new persona you’ve never serviced before? Be prepared, but don’t spend your whole week planning — experiment with the level of planning and details you share in the meeting so that you find your sweet spot. And remember, this may change over time, so be ready to adapt.
How do you make your planning meetings great? Comment below!
