Moving beyond sprint planning

I remember my first sprint planning meeting, many years ago now. And it was a big deal at the time.

Sprint planning was a whole day event on the first Monday of our very first sprint. Many weeks prior had been spent eliciting requirements, compiling the backlog and hiring team members. Now, it was finally time to unveil the user stories.

The whole team looked to me to run the ceremony and provide guidance when needed. Agile coaching and certifications weren’t mainstream then, so I literally carried the Scrum guide around with me.

With the product owner in the room, I presented the stories one by one to the developers, explaining each one as we went. They asked a lot of questions, and the product owner and I answered as best as we could, blagging our way through at times.

But we got lucky. The whole process took 6 hours (not 8), and pretty much every story was deemed good enough to make it into the sprint.

Unfortunately, early success didn’t hold and more often than not in subsequent planning sessions, the whole team couldn’t get through all the tickets in a single day. Also, many stories would end up with so many open questions and ambiguity that they would be parked.

We had been trying to refine user stories in ‘real-time’ during the sprint planning meeting, hoping that enough of them would make it past the developers and into the sprint.

At some point we stumbled upon the idea of refining stories ahead of sprint planning, allowing the team sufficient time to look through tickets, ask clarifying questions and think about possible implementation.

I could also work through anything requiring clarification beyond what the product owner could directly answer themselves.

Multiple refinement sessions each week has worked so well that it’s become a standard practice for the teams I work in, usually occurring two or three times per week.

Continual prioritisation from the product owner means that the correct stories are provisionally allocated, refined by the developer, and then forward scheduled into one of the next few sprints.

Sprint planning now takes 10 minutes, effectively closing the current sprint in Jira, deciding what to do with any WIP, and then clicking ‘start’ on the next pre-planned, fully refined sprint.

Perhaps not your grandma’s agile, but it has worked really well for the agile development teams I’ve been in.