Close
Glad You're Ready. Let's Get Started!

Let us know how we can contact you.

Thank you!

We'll respond shortly.

LABS
Storyation Workshop: How to get business stakeholders to create stories

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.

Comments
  1. Robbie Clutton says:

    I’ve been involved in similar meetings although called something else, the last one was an “ideation” meeting. We ran it not unlike a retro three column format but with the questions: what should we stop doing? What should we do better? What are we missing?

    It was a very free form meeting as opposed to the more structured pre-IPM, IPM and even inception meetings. We wrote each relevant point as a story in Tracker with the headline points having more thought and broken down into actionable stories and moved into the backlog later that day.

    It worked well to break out of the focus that working only one to two weeks out can bring and gave the wider team a chance to get their voices heard.

  2. I’ve been part of processes that tackled this in two different ways. The first being as you’ve described it. If the story wasn’t ready for development then it would roll down the line. It is not ideal but it is one way of ensuring stakeholders take an active interest in the completeness and understanding of their requests.

    The second way was to have a cross functional team meeting each week for an hour to review the backlog and discuss the items in it. The good part with this is that all stakeholders get to hear what is requested. Often there is alignment between groups and needs or needs they didn’t know they had. Having these open conversations allowed task grouping to occur. This also reduced or eliminated requests after the fact because the implementation didn’t quite address XYZ group’s needs.

    As you say, some of this is common sense. However, it never ceases to amaze me how un-common that sense really is and why the post is needed. Thanks!

Post a Comment

Your Information (Name required. Email address will not be displayed with comment.)

* Copy This Password *

* Type Or Paste Password Here *