The team was angry. Every two weeks, they would find themselves five hours into their sprint planning meeting with no end in sight. Every two weeks, it was the same: Their product manager showed up with a pile of requests the team hadn’t seen before – estimated by someone elsewhere in the organization – and wanted to know precisely how many the team could finish in the next iteration. Everyone hated sprint planning. It was stressful, wasteful, and unproductive. Something had to change.
Hitting the Reset Button
By my third day of working with this team, I was pretty sure where the problem in their process was. I’d been part of enough teams to have seen this pattern before. However, I was the only person on the team with experience with agile ways of working outside of the company, so I wasn’t surprised that I was the only one who thought there could be a better way. The rest of the team had concluded that planning meetings were always terrible, and that’s how things were.
After my first two weeks with the team, I suggested running a “Team Reset” workshop. I’d done these half- or full-day workshops before with several groups across the company. They are like Team Kickoffs, except for teams already up and running. Some teams start with practices that seem like a good idea but are not a good fit for their situation. Others begin with behaviors that become less useful because they drift or the situation changes. Team Resets allow teams to reflect on how they are currently working together and make changes. This team had heard about how other groups had benefited from these workshops, so they agreed.
During one part of the workshop, I hung posters for each of the team’s regular events and artifacts. They were doing Scrum, so we had posters for Sprint Planning, Daily Standups, Sprint Reviews, Sprint Retrospectives, Product Backlog, Sprint Backlog, and Product Increment. I asked the team to silently brainstorm answers to “What are these like now?” Each team member wrote their answers on Post-It notes and stuck them to the appropriate posters. After a bit of discussion about what some notes meant, they agreed they’d painted an accurate picture of the current state. And for Sprint Planning, that state was just as bad as you’d imagine.
Next, I asked them, “For this team to achieve its full potential, what would these need to be like?” Again, they wrote their answers on Post-Its and stuck them to the posters. There was a lot of activity on the Sprint Planning poster, including notes like:
- “Everybody understands the stories beforehand”
- “Stories that are fresh in our minds”
- “An understanding of purpose”
- “Acceptance tests fleshed out to the best of our ability before planning”
My favorite was the note right in the middle of the poster that said – in all capital letters – “NO SURPRISES.”
Sprint Planning Was Not The Problem
Team-level planning sessions are some of the most hated events in any delivery process. And yet, my experience is that people don’t actually hate planning meetings. This team had come to the same conclusion I had. The problem wasn’t their planning meeting. It was how they were – or rather, weren’t – preparing for the meeting. Most of the time, when people complain about their planning sessions, they’re actually complaining about two different working sessions that have been invisibly combined into one.
Teams need to do two things in preparation for picking up work:
- They need to understand the work well enough to have a reasonable degree of confidence that they can complete it within an agreed-upon window of time.
- They need to decide what work to start.
Many agile ways of working – including Scrum – have a planning event whose goal is #2. Problems often arise when teams also have to do #1 – which we call “refinement” – because they’ve never seen any of the proposed work before. As we often say in our Scrum training, “Sprint Planning should not be a surprise party for the developers.” When we hear reports of Sprint Planning taking more than half a day, it’s almost always because teams are trying to do both tasks simultaneously. So it’s not that Sprint Planning is taking six hours. It’s that the team has five hours of refinement work to do before they can get to planning. And (surprise, surprise), the quality of refinement done under time pressure, stress, and fatigue is often not the best.
That’s what was happening to this team. They needed the opportunity to hit the reset switch on their process to notice it.
After the Reset
Every agile team that I’ve been part of since 2008 has been able to plan a two-week iteration in under 90 minutes. How? They spend time continuously looking at upcoming work, understanding its value, and breaking it down into smaller and more precise pieces. This refinement activity is not the sole responsibility of a product manager or domain expert. It’s a team-level activity that, when done well, makes planning sessions relaxed, useful, and productive. And that’s what was missing with this team – at least until they hit the reset button.
Once they could see that improving their planning meeting required making changes outside of it, they knew what to do. The notes they collected during the Team Reset helped them understand what their standard for refined work – work that was ready for planning – was. They made a short checklist out of these notes to refer to later. They also set aside regular time for refinement: Two hour-long blocks each week with the whole team. On days when these were scheduled, the product manager would let the team know what they needed to refine that day. If enough work in their backlog was ready for planning, they’d cancel that day’s session. And before they marked any work as ready for planning, someone would check it against the team’s checklist.
This new process took a few weeks to get used to, but it paid immediate dividends for the team. There wasn’t always much difference when you added the time the refinement sessions took to the length of the newly shortened planning meeting. But the team’s planning improved considerably. There were fewer “surprises” where the work took substantially longer than expected. Because the team considered use cases and code paths more carefully, they had fewer defects. And planning went from the meeting everyone hated to something that was “no big deal.”
Hitting Reset on Your Process
Are you working with a team that might benefit from a Team Reset? Ideally, every team has a robust process for reflection, learning, and improvement – like Scrum’s Sprint Retrospective event – that helps them improve their process on an ongoing basis. When this doesn’t happen, stepping back to do something like Team Reset can be valuable. Processes and practices aren’t the only things that get looked at in these workshops. In my experience, hitting reset on your team-level processes is one of the most effective ways to improve both the quality of work that the team delivers and people’s experience.
