My Stories Are Too Short… And Too Long…

I often find myself siding with old-school agilists who believe that teams (and their product managers) must continually experiment their way to good processes and collaboration, rather than “best practices” folks who believe there’s a fundamentally right way to do things. I take the position that categorical imperatives are always wrong.

Here’s an instance to work through…

“My development team tells me that my user stories need more detail.”

A Grossly Unfair Generalization

But as product managers, we need to hear what folks say and then dig aggressively for underlying issues. We listen skeptically when a paying customer tells us how to fix something. We don’t transcribe requests verbatim and hand them over to our development team. Instead, we unpack and question and validate and look for patterns across the user base…

So “my development team tells me that my user stories need more detail” deserves the same thoughtful inquiry. All stories? What’s missing? Is this leading to bad software, or just additional conversation? Are user stories the right way to fix what’s wrong? How do we understand this comment if (last week) we heard the opposite? This could be a real team-wide headache or general grumbling or one developer’s assumption that a product manager’s only job is to write perfect user stories.

And notice that I can’t resolve this issue in my own head: it requires talking with my team, extracting real opinions, and collectively dissecting those opinions. Applying good product analysis internally. Collaboratively agreeing on next steps.

Let’s Unpack This as a Team

Maybe it’s just grumbling, and no one really cares. Most of an hour sounds like a lot, even though we waste that every day walking to Philz for designer coffee. But if it’s a real irritant, the team should be willing to make time.

Assuming we’ve agreed on a meeting, let’s also redefine the problem to be more specific, more tractable, less universal: “I’ve heard that my stories are too long and too short. Possible that both are true for different kinds of stories. Let’s look over 8 or 10 different stories, get your quick votes on which are too long or too short, and why. We might notice some patterns about WHICH kinds of stories are in each pile. Or how to improve the story cycle.”

That gives the team a framework for more constructive discussion and shared empathy as we inspect actual examples. We fight recency bias by looking carefully at the data. The last time I ran this tiny exercise, we collectively identified a few different kinds of stories, each needing its own treatment:

[1] Highly technical, not much product management value

I was unintentionally annoying the team with pages of commentary, self-evident restatements of business value, and naïve technical suggestions. My audience (i.e. the development team) wanted just a few things: test boundaries and dependencies. So I could reduce their frustration while doing less work — if we could sort the right stories into this category. Time saved, blood pressure reduced.

[2] Heavy user interaction, designs mocks, workflows

We identified that my user stories were getting in the way: shoehorning nuanced design work into story templates and discarding important context.

We agreed to run an experiment for a few weeks: attaching full design mocks to succinct stories and scheduling a whiteboard walkthrough for our designer, the two developers most involved in that workflow, and myself (to take action items). If that didn’t go well, we’d try something else, because results matter more than formalities.

[3] Validation experiments

And they had tremendous insights into good experimentation, once everyone was included. (“Here’s another possibility for why prospects are dropping out of our funnel at step 3b.” “We’re already getting response data from email campaigns. Can we use that instead of adding new landing page instrumentation?” “Running the experiment that way will take months to gather statistically valid data. Instead, let’s try…”) Smarter validations, shared context, and more passion for the work. Plus, it helped that we called these ‘experiment design sessions’ instead of ‘meetings’ because everyone hates meetings.

[4] Goldilocks stories

Your team would (of course) come up with other issues and categories and reactions. But notice that a single, canonical, obligatory, fully-realized “best practices” user story format will fail us in different directions depending on the problem at hand. And will add dozens of hours to our product management week — creating unneeded content that our teams may ignore, or have to slog through — instead of focusing our limited time on what drives real product outcomes.

So I generally lean on the broad agile principles that start with “valuing individuals and interactions over processes and tools” before accepting procedural assertions. Standups are valuable if we run them well and know why they add value, especially if we’re willing to experiment with alternatives. Estimation is essential to stay in business, but there are lots of techniques beyond Planning Poker. (Here’s one from Ron Lichty that I love.) Scrum is good except when it becomes dogmatic or inflexible or self-important.

I’m deeply skeptical of best practices and consultant/trainer-provided frameworks and one-starting-point-fits-all. Building great software is much more like writing a best-selling novel (or a hit song) than digging a ditch, so we have to engage our whole teams’ full talents to create brilliance.

Sound Byte

_________________________________________________

* From my limited sampling, I see less of this dynamic in more diverse teams, especially where women and other under-represented folks feel they belong, are respected, and actively participate in conversations. As product leaders, we can carefully moderate discussions so that every important observation is heard. See more excellent thoughts about inclusion at Better Allies.

** Retrospectives may be the most important agile ritual, and they depend on trust. Every week (or two), the whole team should share what’s working — and what’s not working — with the generous assumption that everyone is doing their best. “What can we try next week?” Organizations and processes are the usual culprits. Here’s the classic reference on retrospectives.

Photo credits: PostIt by AbsolutVision, Latin book by Mark Rasmuson, workflow from Campaign Creators. All from Unsplash.

Originally published at www.mironov.com.

Tech start-up veteran, smokejumper CPO/product management VP, writer, coach for product leaders, analogy wrangler, product camp founder.