I find it ironic that one of the most fundamentally important aspects of Agile planning is so very often terribly implemented. User Stories are the single most important thing that a Product Manager/Owner delivers to their development teams — they’re the foundation on which everything the team does is gauged; and all too often, quite frankly, they suck.
The impact of the vast suckitude of these user stories is far-ranging, and does not go unnoticed. Bad user stories are one of the biggest causes of complaints on the part of development teams, the cause of endless friction and misunderstanding on the part of stakeholders, and ultimately result in missed deadlines, failed sprints, and Armageddon itself. Okay, maybe not quite that last part, but it sometimes feels like it.
So what are you doing wrong? If you’re like many PMs that I’ve seen struggle with your User Stories, it’s one or more of the following:
1. Your stories aren’t user-focused…
I know, I know — there are lots of theories about what a “user story” is and what it should be. By far, the best and most useful format that I’ve seen is the “User [x] needs to [y] so that they can [z].” format. It works best because it is 100% focused on the user, their goals, and their planned execution path. In practice, this means that you’re telling your developers clearly what you’re trying to achieve, who you’re trying to achieve it for, and why it’s important to the user. There’s no abstraction to a system or an ideal user or some black box that says “do this,” rather there’s an actual story that the developers can envision from that specific user’s perspective. This lets them solve the problem that you’ve defined, without telling them how to do their job. It allows them to use their creativity and their technical skills to build the best possible solution for your user and your business and that is one of the reasons Agile approaches are so successful.
2. Your stories aren’t conversation starters…
Too many Product Managers, especially those who come from a more traditional waterfall approach, tend to use their User Stories as a replacement for the kind of detailed, explicit, fully-baked requirements, rather than the kinds of open discussions that User Stories are intended to start. This can be a hard change to make — especially if there are business-side stakeholders who still expect the kinds of detailed requirements they’ve seen before. But that’s also tying yourself to the old, bad habits of a waterfall mindset. The reason that User Stories are intended to start conversations is that they establish a trusted relationship between you and the development team; they respect the developers as problem solvers and doesn’t patronize them as mere order-takers, checking off a list of specific deliverables. Conversations are good – they allow people who know their individual domains to collaborate and elaborate on things that any one person might miss, because they lack the context to fully understand the implications of the requirements. User stories need to be conversation starters — that’s how this works for everyone involved.
3. Your stories are too big and broad…
Another problem that User Stories offer suffer from is that they’re too big and too broad — “A new user needs to register their account so that they can access the site.” is way too big to be useful, even if it’s user-focused. A story needs to be big enough that it doesn’t confine the development team into a specific solution, but it also needs to be small enough that the team can get their arms around it and provide a reasonable estimate of the complexity and difficulty of doing the work necessary to execute it. Stories that are too big, or too broad, or (God forbid) too vague lead to nothing but frustration on the part of the development team, and they leave way too much room for interpretation by your stakeholders — who will gladly fill in the gaps with their own unspoken, detailed expectations. Ensuring that your stories aren’t so big that they can’t be properly scoped or understood is absolutely necessary to ensure that your teams can make and keep their commitments, and that your stakeholders can understand what it is that they’re actually going to be getting. Managing for estimates and expectations is one of the key things that a Product Manager/Owner needs to do every single day.
4. Your stories are too small and narrow…
Of course, you can always go way too far in the other direction, making stories that are so small and narrowly-focused that there’s no wiggle room, or that there is no creativity or individual input to be provided by your development teams. When you find yourself specifying colors, fonts, or button locations in your user stories, you’re way too far in the weeds, and you need to pull yourself out to tree-level and try again. It’s tempting to go into the minutiae of your product when you’re creating your user stories — after all, you are the one who knows the user, you are the one who knows the market, and you are the expert about the product! And, of course, you want to make sure that your stories can be estimated — and the smaller the story the more accurate the estimate, right? WRONG. Defining your stories too narrowly inevitably leads to missing something along the way. Narrow stories are just as dangerous as broad stories. You’re looking for the Goldilock’s story — not too big, not too small, just right.
5. Your stories are unstructured and random…
Way too few PMs really understand the purpose or use of Epics and Themes, and how they relate to your User Stories. User Stories that are abstract and unrelated are like kryptonite to an effective development team — they sap their strength, their will to live, and (most importantly) their faith in you as a Product Manager/Owner. A PM or PO is only as good as their backlog, and that backlog is a reflection of their approach and their personality — the more structured and organized the backlog, the more structured and organized the PM. And this relates directly to the amount of trust that you buy yourself in the organization as a whole. Using Epics and Themes to structure your user stories so that they directly and clearly relate to the strategic goals and direction of your company is a very quick and easy way to demonstrate to everyone that you interact with that you know your stuff and that they can rely on you. Disorder in the backlog results in disorder in your execution, every single time.
