Today someone asked me what I considered to be the most rewarding part of product management. Immediately, that quiet moment after sprint planning is complete came to mind. As the team files out of the conference room and I’m breathing a sigh of relief, I feel an incredible sense of accomplishment when the team has tasked out the sprint stories, we’ve managed to balance development and QA work loads, and everyone is excited to build the next feature.
That’s a mighty tall order! If all has gone according to plan, the following things have come to pass:
We’re doing the right thing. I’ve worked with the business owner and prioritized the product backlog properly so that we’ve chosen the right thing to work on next.
We’re doing the right sized thing. I’ve worked down the chain from the business owner through the architect and the development leads to tease out the requirements of the story in the context of a larger epic deliverable. Everyone has an understanding of what we’re trying to build, and we’ve bitten off just enough of it to complete in a single sprint. For this reason, I’ve found planning poker to be the single most valuable planning activity outside of sprint planning.
Everyone has some understanding of the thing. No one wants to hear about a feature for the first time during sprint planning. It makes a world of difference if the team has an idea of what’s coming up in the next sprint. We’ve talked about the release scope, we’ve done planning poker, there have been informal discussions across cubicle walls with a cup of coffee. Gaining clarity is a two way street – I’ve lost count of the number of times I’ve run back to my office to add requirements to an upcoming story or to add a new story to the backlog given an informal conversation in the hallway. It makes such an incredible difference during sprint planning when the acceptance criteria for a story are clear and concise.
We’re working as a team. I’ve been fortunate to work with a few great teams over the years that shared the common goal of building great software. These teams were characterized by a lack of ego, a willingness to step outside their comfort zones, an understanding that we all make mistakes (and that’s ok, but let’s learn from them), and a commitment to update the process to do it better next time. Let’s make different mistakes.
I’m lucky to have had more than a few of these quiet reflective moments over the years, and looking forward to more adventures in software development.