What’s the Point of Writing User Stories?

I’ve recently been working with a client who told me they had worked in an agile environment before, had found it valuable, and wanted to use it again. After running two or three grooming sessions of the product backlog with the development team and customer I was asked what I thought the point of writing user stories was. Many people who have worked in quasi-agile environments think that user stories are agile’s equivalent of requirements gathering. They’re wrong.

What User Stories aren’t

I’ve worked with managers who think that the team should have nothing to do with requirements gathering, and have as little contact with the business stakeholders as possible. Sure, they know the manifesto says that developers and the customer should have daily contact, but that’s what the stand up is for…

Some teams end up with either a BA or (even worse) the ScrumMaster writing user stories from an Excel spreadsheet that has been delivered by a PM – perhaps one masquerading as a Product Owner. Once these user stories have been written with some bullet points that poorly reiterate the content of the user story that have a title of Acceptance Criteria, then they are deemed ready for the team to work on.

Imagine a news app, that the publishers want to include videos inside articles. The publisher has written this story:

As a user
I want to play videos
So that the user has a good experience

Acceptance Criteria

  • Videos can be played
  • User experience is high quality

Great. The team now knows exactly what they need to do. Right? A team of developers know what a high quality user experience is, and it is of course the same as the publisher has in mind. The publisher has also told the team that the video just needs to play. It certainly doesn’t need detailing that it must be played in app at full screen, because the customer covered that in high quality user experience. The team knows that videos need hosting, so they request some server space for this, which is a shame because the publisher is happy with their current hosting provider.

It’s easy to see how this will end up in an unhappy publisher, and a development wondering where they went wrong.

What are User Stories?

If a development team and product owner is lucky enough to have a BA to get user stories into the product backlog, then the user story above is a great starting point for the conversations to come and can save a lot of time in grooming sessions. Otherwise, the Product Owner owns the backlog, and it’s their responsibility to make sure it’s ready for grooming.

User stories are written in the script so that we can extract very specific reasoning from the customer.

As a = Who is it that is going to get the value delivered by this work?
I want = What is it that the person getting the value wants from the work?
So that = Why? What is the value that this work will deliver? How do we measure success? What is our guidance for a solution as our understanding of the problem grows?

First Conversation

After facilitating a conversation with the development team and the customer, they came up with this:

As an employee using a BYOD mobile phone
I want to play videos posted in articles
So that I am more engaged in the content

Acceptance Criteria

  • User is using one of a given set of Android mobiles
  • Videos will be linked to in an article
  • Videos will be hosted on the company’s video platform
  • Users should be able to watch the video full screen in app

This is much better! Both sides have a better understanding of what is required. The development team now have an understanding of why this piece of work has come to them, and the customer understands how many decisions have to be made just to play a video. The bonus for both sides in this process is that the customer has been involved in making the high level, non-technical decisions; the development team didn’t guess wrong and the customer won’t be surprised.

Second Conversation

As an experienced agilist though, I noticed that the value proposition – the So that… – didn’t ring quite right. Are we really putting in all this effort to keep the user engaged? Does the user really want to be engaged by videos? Cue more conversations that led to:

As an author
I want users to be able to play videos posted in articles
So that they learn more about our business and keep up to date

Acceptance Criteria

  • User is using one of a given set of Android mobiles
  • Videos will be linked to in an article
  • Videos will be hosted on the company’s video platform
  • Users should be able to watch the video full screen in app

Now you can see that the acceptance criteria are not repeating anything that is contained inside the user story itself and so no effort has been duplicated. As everyone discussed the whole story in detail, everyone has a sense of ownership of the work item. The development team could bring a perspective that the customer was unaware of, and the development team understand the customer’s need better. There’s an added bonus that if anyone who had to miss the grooming of this story picks it up they will see the essence of the conversation.

What is Value?

The latest user story and acceptance criteria are great examples of tangible output from a short meeting, but as ever it is the intangible that contains more value. The outcome of the meeting was that both the customer and the development team had a better understanding of the work, and therefore a better chance of building something that really satisfies the business and their customers.

As organisations move into the agile space it’s important for everyone to have an understanding of what the differences between output and outcomes are, to be able to see that both have occurred, and to be glad.

Leave a Reply

This site uses Akismet to reduce spam. Learn how your comment data is processed.