I remember my first sprint planning meeting, many years ago now. It was a big deal at the time.
Sprint planning was a whole day event on the first Monday of our 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 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.
We got lucky. The whole process took less than a full day, and every story was good enough to make it into the sprint.
Unfortunately, early success didn’t hold and in subsequent planning sessions, the whole team often couldn’t get through the tickets in a single day. Some stories would end up with so many open questions and ambiguity, that they would be parked for another time.
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.
Eventually, we stumbled upon the practice 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 work through anything requiring clarification beyond what the product owner could directly answer themselves.
Continual prioritisation from the product owner means 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.
Multiple refinement sessions each week have worked so well that it’s become a standard practice for the teams I work with.
If you are unhappy with your development team, they may need more detailed guidance.
Better software requirements can help with this.
|
Frank Ray Consulting. Software requirements for agile development teams, particularly remote, outsourced and offshore development teams working in financial services. |