Agile and Stories - Breaking the Mould

The other day one of our ELMO Product Owners thanked me for a session we (Paru Madhavan , Emily Sattout and myself) had run 4 weeks ago. The session was on Stories, a topic near and dear to my heart.

In thanking me he said something that stuck in my mind: “I used to spend ages trying to make sure I got my story ‘right’...”.

Alright Agile world, take a seat. It’s time to talk. Where did “people over process” go?

I used to hate the word ‘process’. As a young person I thought process was an unnecessary constraint that tried to put me in a box and slowed me down. Now, as a more mature employee I can see that, at times, homogeneous ways of working can actually facilitate me getting to the fun stuff faster.

Yet, even as I leave those views behind, I am still wary of any ‘process’ that may cannibalise weight from conversations and innovation.

When I found Agile, I was instantly hooked. Here was a group of people who thought as I did, worked as I wanted to work, valued things I valued and got stuff done.

The manifesto should be a document that lives in and through us all. Customers over contracts, people over process… these are tenets that we should embody in our ways of working not because a document says so, not because it’s the ‘latest craze’, but because it makes sense.

Dogma isn’t Agile

Unfortunately, in teaching the constituent parts of Agile, the things we ‘have to do’ take on a rigid, dogmatic aspect. A perfect example is stories.
What could be more fundamental to Agile ways of working than the humble ‘story’? It is everyone’s first slice of the pie: a little post-it note, stuck on a wall with a few tantalising phrases on it. We take that post-it and then, through magic and hard work, we turn it into software and there’s your fairy tale ending.

Writing stories is a skill, and being a skill it needs to be taught. That’s understood. But how we teach this skill is really important.

A ‘story’ isn’t “As a… I want… because”. I have seen an uncountable amount of JIRA tickets that meet the heady construction criteria only to be dangerously useless when it comes to actually getting stuff done.

To my mind it is absolutely mental that people just starting out in Agile think they have to slave over their story construction to make it fit a mould.

Don’t ignore short cuts

The industry has found some healthy shortcuts for you. This is going to sound antithetical to this post, but the “As a.. I want.. Because” construction is one really good example of the industry reaching out to say ‘here’s something useful to help you work faster’. You shouldn’t ignore it, but you also shouldn’t be bound by it.

Jeff Patton, someone we should all be familiar with, says that stories are the beginning of a conversation. The conversation is what is important. I don’t seek out colleagues just to use them to get my job done. I want to collaborate, I want to listen, I want this to be a collective endeavour because that’s so much more fun and thus more rewarding. To that end I’ve actually had great success in flipping Mr Patton’s wording while keeping the meaning alive. For me stories are a reflection of the conversation which has already happened.
What makes a good story is not whether it fits the mould, but whether it accurately, clearly, logically and with an eye to outcomes reflects the solution you and your team are already dying to build. When someone in your team sees that story they should clearly see what it is you and your team are trying to accomplish. That’s all it is.

Break the mould

A story could be a picture, a story could be a few dot points and a story could be ‘as a… when I… because’. The test of whether you’ve written a great story is that every person reading it comes away with the same understanding of:

• Who are you building this for?
• What problem are you trying to solve?
• What value will that stakeholder get after you solve it?

As a team member I already know all of that. All I’m doing now is jotting it down!

Conclusion

As people working in software we are privileged to be able to make a positive, material difference in people’s lives with the literal push of a button. To anyone just starting out in Agile, or to anyone who hasn’t had the mental space to think outside the model, here’s a short cut: We turn up to work to make our customer’s lives better. Do that, in the fastest, safest, funnest and cheapest way you can and you are doing great!

So use the mould, don’t use the mould, who cares? What matters is that the story helps your team build the thing they want to build faster, with no misunderstandings and with an eye to value so that, at the end of every day, we have changed our customer’s lives for the better.