Getting more story in the user story

The first time I was asked to write a user story, I was utterly appalled:

As a user, I would like to have a shopping basket so that I can clearly see everything I have added to my order.

What kind of story is that? And why does every story sound the same?

As a <SOMEONE>, I would like to do <SOMETHING> in order to achieve a <GOAL>.

And why do I need to make it sound like a piece of literature at all if I still have to write a list of acceptance criteria afterwards?

• [AC01] The shopping basket is always one click away during the shopping process
• [AC02] All items are listed in the shopping basket with a title, picture and description
• [AC03] Items can be removed and the quantity of them can be changed
• [AK04] The user can choose whether to continue shopping or initiate the payment process

Understandably, it makes you wonder why you need to start the process with that poor excuse of a story in the first place.

A missed opportunity

I think there are good reasons for writing real stories in backlog items – user experience (UX), customer centricity and, last but not least, motivation.

Same example as above: evidently a shopping basket is supposed to be built for a shopping website, so we can keep the acceptance criteria. Technically, it is exactly the same thing that is supposed to generate product value at the end of the next increment.

But how about the following introductory story:

Petra has found several products that interest her in our shop within the last half an hour. She would like to put them all in one place, have another look at them and then (hopefully) order them when she has finished browsing, just she like she can in other online shops.

We want to provide her with – as creative as it is – a digital shopping basket for her to put her items in.

Sure, the story is longer, less concise, peppered with superfluous information and the informal use of language makes it seem less professional. But it is much closer to reality than the copy you find in a traditional user story. The new story has a background, a main part and an open ending. The story now even tells you what the business case is for implementation: it improves the ordering process.

And like any real story, our user story now even has a protagonist.

User stories and personas – stories need main characters

And ideally, the product owner does not even have to come up with this protagonist themselves. If UX experts were involved, then the project documents probably already contain personas for the potential user group. So why not incorporate the characters from the painstakingly created personas as heroes in the user stories?

Integrating personas and user stories like this also helps to the team become aware of the different user types. A team that all know who a tech-shy Tim (29) or an impatient Ingrid (19) is can develop software for these groups of people more efficiently.

Another advantage is that the dev team is not then forced to use personas by being constantly told to ‘please remember the personas when you do frontend implementations!’. Instead, everyone involved gets to know the different user groups naturally by association.

Collaborate instead of blindly working through acceptance criteria

Items in the product backlog should not be painstakingly precise, rigid, binding contracts or requirements catalogues. Rather, they are living working documents that ideally mature with the product and/or project. Or, as the Agile Manifesto would say:

Individuals and interactions over processes and tools and customer collaboration over contract negotiation.

In my view, traditional user stories do not offer the team enough opportunity to stretch their creative legs. On the contrary, you tempt product owners to put overly polished backlog items into development, which nip any motivation for independent thinking in the bud.

Everyone on the team can identify with a real story – no matter what their role is or what their background is (technical or otherwise). You can talk about a story, seeing as it is personal, provokes an emotional reaction and stokes the flames of creativity. People are storytellers, so why not take advantage of this fact and present tasks in a natural, motivating and possibly even fun way.

But does this also meet INVEST criteria?

Scrum experts are familiar with INVEST as an evaluation standard for user stories/backlog items. The INVEST criteria are often even anchored in the definition of ready (DoR):

• Independent
• Negotiable
• Valuable
• Estimatable
• Small
• Testable

I personally see no reason why adding real stories to user stories would cause them not to meet INVEST criteria:

• Independent remains untouched, as we are only changing the format.
• Negotiable is actually improved, as now there is actually something to talk about.
• Valuable, like independent, is not affected further by the story being better.
• Estimatable is fulfilled at least to the same extent as it was before, if not better – after all, the more detailed picture of the user you gain may enable you to provide a more accurate assessment as to whether or which quality requirements need to be fulfilled.
• Small refers to the scope of the requirement and the duration of the implementation. The user story itself will of course be somewhat longer.
• Testable is also fulfilled in the same way as a traditional user story, as the acceptance criteria remain the same.

Conclusion

It goes without saying that the conditions need to be right to test such an unusual method. If there is not much going on in the project with agile anyway, it is certainly advisable to start with established best practices in the wonderful world of agile software development.

But a well-rehearsed agile team can only win if it allows itself more freedom in the user stories. I will definitely try this out as soon as I get the chance. I will let you know how it goes.

You will find more exciting topics from the adesso world in our latest blog posts.