I read Lean From the Trenches last weekend and it was great. Not because it provided black and white protocols for running an agile product development team, but rather because it showed how a real team operates under real conditions.
I want to focus this post on a quote from the book:
The definition of “ready for development” can be achieved only if all specialties work together to estimate features, break them into small enough deliverables without losing too much customer value, and to agree on acceptance tests.
Ready for development is an interesting concept — it implies that every business stakeholder that has input knows what the product owner needs to ensure a developer can deliver an acceptable story. In my experience, this is usually not the case once a product is out in the marketplace and people from non-product teams (marketing, support, executives) have specific product needs. This could look like promo code tracking to support a marketing campaign, or a data export to support your “data science” team. Without a good process for getting these stories into the backlog, the result is an unhealthy IPM where the PM and developers have to divine what exactly the intent of a story is.
At one of my last companies, we had this problem in spades. Even after introducing a Pre-IPM meeting, we still felt like the quality of the stories we presented to developers in IPM didn’t represent the time we had spent discussing them. To add insult to injury, getting the story requester to accept a delivered story was like pulling teeth. Once we did sit them down to walk through a story, rejection was often the result!
After reflection (and seeing this come up as a theme in several retros) we created a new weekly meeting called “Storyation Workshop.” This session felt a lot like office hours, and we made clear the intent to only let high-quality stories into the backlog. We (PM and Tech Lead) would do our best to interpret the needs for a feature and turn it into actionable stories. We would also break out the necessary pieces from the nice-to-haves. Make no mistake, though — the business owners were on the hook to bring justification for a feature and if it didn’t pass muster it lived in the Icebox for another sprint.
We were fortunate (as a company) to have support for keeping a healthy backlog and not jumping stories in the priority queue. I saw many benefits to this new process:
- All the other teams — marketing, professional services, customer support, data science — paid closer attention in IPMs and made sure that their needs were well represented
- Acceptance happened more quickly after a story was delivered, and expectation alignment meant rejections went way down
- Everyone got better at story writing as they started to grok how we broke down features and the logic behind it
- More greenfield thinking popped up and made it into the backlog as actionable work
The first three were proof to me that we were missing a critical process in the arc of a story. The last bullet (greenfield thinking) was a pleasant surprise. It turned out that people were afraid of bringing a half-baked idea to IPM (rightfully so) but didn’t feel like they had the right forum to finish baking an idea.
Maybe this all sounds like common sense; if that’s the case congrats on having a healthy product development process! For anyone struggling to deal with symptoms like these I suggest you try introducing a safe space for new ideas to come to light. A Storyation Workshop could come in many forms, but you’ll know it’s working when you see more buy in from non-product team stakeholders and a faster cycle-team for their stories through the backlog.
As always, I’d love to hear if you’ve incorporated a similar technique into your agile product development process.
