I’ve been watching my team for a couple of sprints now, and I’ve generated some questions around how they groom stories. When stories are brought into sprint they are typically between 25% and 50% of the team’s average velocity. The ideal is that every story is around 6% to 10% of the average velocity. The Team and Product Owner have been telling that they cannot be made smaller. I didn’t believe this and so decided to explore a story that the Team claimed to be ready for the next sprint.
My suspicions that things were wrong further upstream than the sprint came from two things that I had observed during my first sprint with the team. Firstly, I was seeing a lot of emergence coming out of stories in sprint. Our product has recently been handed over to our in-house team after originally being developed by an agency. This agency had left technical debt behind, and it was becoming clear to me that the Team have been fixing much of this along the way. Add to this the usual environment issues one expects in most immature agile teams, and we see the throughput become highly impeded.
The other unusual thing I had spotted was the way in which grooming was conducted. The Product Owner would give a brief overview of the ticket’s requirements, ask if there were any questions, and then the team would vote on story points using their fingers. I could see some were waiting to choose their score until they saw how others were voting. No conflict was being exposed. No discussion of what would be technically required to fulfill the user need was had. At the very least I would hope to hear what business value would be delivered by the work and how that fits into the Product Vision, but I didn’t.
With my first opportunity to facilitate a grooming session I chose to review the top few tickets from the Product Backlog that were supposedly pointed and ready for the next sprint. The first ticket passed through quickly enough, which was unsurprising as it was a technical requirement generated by the team. The next ticket was a product value user story that the Team had voted as a 5 point ticket. We performed a quick overview followed by a longer discussion into a high level plan of how to create a solution. I captured questions as the discussion flowed and we returned to answer them at the end. When we had a satisfactory amount of ticket breakdown we played planning poker with real cards, discussed why there was divergence, revoted multiple times (to the shock of one developer), and found an extra 21 points in this 5 point ticket.
Without having the Team and Product Owner talk in detail about why we are doing what we’re doing, how we’re doing what we’re doing, and exploring the impact the new value will have on the Product and vice versa, there will be confusion. For humans, confusion leads to distrust, blame, and lies. Story points are not about a consensus or measuring velocity, but rather about unearthing conflict and tackling it head on, removing knowledge silos, and giving the Product Owner an insight into their Product that only the Team have. For the small price of a couple of hours of meetings each sprint, the Team and Product Owner will work together as a single unit to produce a valuable Product desired by the customer.