In recognizing that too many of our user stories were not truly ready to be implemented, I decided to revisit the entire path to grooming
For months, I had been watching the Product team wrestle with getting their particular features out the door and in front of our customers. And it wasn't just one PM who was struggling or an exceptional delay in delivery - it was borderline chronic. More often than not, I could trace the issues back to poor preparation by the Product team.
I have been working with our entire tech team to continuously improve our own Agile development process and we certainly have more work to be done. But the problems I needed to address were further upstream, before the stories entered the Engineering and QA queues. The Product team was creating unnecessary thrashing by failing to do our part well.
What drove this decision
When your product releases are scheduled less frequently (think months apart vs. weeks), there is a greater impact when you miss a delivery date. I was frustrated at having to drop features from a release because they weren't ready or seeing enhancements slip to the next sprint.
And while it is tempting to spread the blame across the myriad variables that go along with shipping product software, I became convinced that my own Product team had to step up to support our share of the contract.
Some product planning failures are easy to measure. Are features not being completed? Are your stories slipping over successive sprints and even releases? Are your Engineers and QA teams stalled waiting for last-minute clarifications around designs and requirements?
The decision: Formalize the team's story preparation process leading up to sprint planning
The bad/good news was that we had accumulated sufficient instances over the past few months to see some a pattern emerging. Early on, we tried using note cards and a whiteboard to better track the larger product initiatives over sprints and releases. This seemed promising at first, probably because the team appreciated an exercise that was both tactile and collaborative. But we ultimately failed to capture any incremental advancement of any initiative using the cards. Moving the cards across the board from sprint to sprint didn't make us better at preparation and worse, this exercise did not help us identify deficiencies in the planning process.
We needed a different approach, one that helped us focus on maturing product requirements BEFORE we gave them to the team. We needed a better product grooming process that preceded the actual backlog grooming sessions.
Plan of attack
The tactics described below were prescribed only for our larger product initiatives and would likely be overkill for bugs and smaller feature enhancements. We began by focusing on the problems that occurred most frequently, then folded in additional steps to mature the pre-grooming process.
STEP 1 - Include the fully baked UX designs
Perhaps the most obvious problem for our team was that we were often scrambling to get our front-end designs in place by the time the Engineers were ready to estimate the level of effort. We had become less and less stringent about completing the UX work and ensuring that formal designs were attached to a story or epic prior to backlog grooming or worse, sprint planning.
The lowest hanging fruit, then, was to re-establish this specification for all our user stories. Going forward, no stories would be allowed into a backlog grooming session unless the designs were complete. Obviously, there is no real definition of "fully baked" as teams will inevitably tweak designs during development and even testing but this was a relatively easy first stake in the ground.
STEP 2 - Review the acceptance criteria with internal stakeholders
I'm of the mindset that you can never stop improving on your ability to define product requirements. I encourage my Product Managers to continue to work on this skill with each new assignment. But there is an easy to tell whether you are actually improving or not by gauging how often your stories are being kicked back by the Engineering or QA teams.
And even if you are scoring well with these groups who are much closer to the code, you probably have other stakeholders inside the company that can help you measure your aptitude. In our organization, the Sales Engineering and Professional Services teams are great early sounding boards. Another important group (for us and most organizations) is the Customer Support team. Each of these groups is intimately familiar with your customer base and can help validate how well you have done in capturing the happy path(s) and the larger set of user variations.
In our updated process, we have a specific gate for reviewing stories or at least the acceptance criteria with our internal stakeholders. This has the additional benefit of not catching them off guard during a Release Preview for example, when the feature is already "complete".
STEP 3 - Weave in usefulness testing with end users
When it comes to testing products with end users, excuses usually outnumber opportunities. Like most Product teams, we would prefer to have more time to spend with our customers but scheduling these interactions always seems more difficult that it should be. Still, the team and I firmly believe this is a critical part of the grooming process - especially as the requirements and designs come together.
Going forward, we have made this an explicit stage in the lead up to backlog grooming. Of the steps listed here, it is the most challenging to implement but will likely have the biggest payoff. I can think of nothing better for removing doubt and minimizing surprise than having end users validate your product throughout your development process.
The Product team is still adjusting to the new approach although we all recognize the improvements that will come with better story preparation. We've already seen some of those benefits: in the past few weeks, we withheld a number of stories from backlog grooming that had not met the new criteria, saving us hours of guaranteed thrashing with the Engineering and QA teams.
Additional refinements will be necessary. As we advance and extend our customer research and user testing, we will introduce new gates in an effort to further solidify the product features and push them through our Agile process.