User stories are hard

Tales from the front line.

We need to be careful in just accepting something without at least questioning it from time to time. Agile is a great concept and I’m fully supportive of it, but what I’ve realised is that user stories aren’t a magic bullet that will somehow make project delivery easy.

I get it, you want requirements to be more goal oriented and user focused, something that can be read by all, but after a decade of delivering agile projects I’ve seen this break down on the majority of projects.

If a project has been more successful than others, I haven’t observed that it’s because of user stories. Stories are good at dividing up responsibility across a build team, but in my experience they do not make it easier to understand what we need to build, which is where I experience most problems on projects.

The key issues are I’ve observed on most projects are:

• Things have changed… we have more tools than ever now to describe something through rough prototyping, rapid development and drawing
• We completely forget the principles of agile. We’re meant to be spending more time on building software than documentation
• Stories are hard to understand, even though they’re meant to not be
• They’re hard to understand because they don’t have the surrounding context or journey embedded around them
• Business users do not find it easy to read stories. I’m a tech guy and I find it difficult to understand what we’re building when I’m just looking at a list of stories for the first time.
• We aren’t used to thinking in stories. When I want to drink a coffee, I want to drink a coffee, not ‘I want to enjoy a hot caffeinated beverage so that I can feel warm fluid and quench my thirst and provide an energy uplift”. Followed by several stories about a kettle and a mug and endless acceptance criteria about switches and porcelain handles.
• Applying INVEST principles to stories is most of the time not adopted and usually requires coaching
• A large amount of time is spent assessing, grooming, reviewing, approving stories instead of just getting it done. Again this was never the intention of agile or SCRUM, it was about spending less time on the overhead

Some things that make stories work:

• Stories come last, not first. First do everything but stories. Use prototyping, journey maps, post it notes. Once you know what you need to build, then document. Requirements follow prototypes, not the other way around.
• Build your way through it. When figuring out requirements, just build, mock up, draw, prototype, then present it, then go again.
• Every story needs to be on a story map or a journey map. It needs to be visual
• Stories are good for dividing up tasks for a build

This isn’t a post about stories being bad, they’re not, they play a role. This is a post about suggesting that do not assume that user stories make project delivery easier for everyone. They’re a tool, but to build a house you need several different tools.