The User Story Mantra

May 24th, 2017 by Lieuwe van Brug

The backlog is at the core of every Agile Scrum process. The backlog is a the worklist of the team. A common way to write down the functionality using the format of User Stories. This is a formula to define for who this functionality is, what the functionality is and why it should be build. This translates to a format like:

As a who I want to be able to what, because why

So you'll describe all three concerns (the who, the what & the what). This looks very concrete and to the point: You write down a user story for a user or customer, describe what is necessary and provide a reason why it is needed.

So what is wrong?

Well, if you apply this to the letter in reality, a lot could go wrong. Let me give some examples of what could go wrong:

A lot of functionality cannot be described in a single line. Due to the format, in reality a lot of functionality is written down in one single line 'because the mantra tells you to do so'. Because of the user story mantra, functionality is written in that formula and there is no room for details. Or even worse, for every detail a separate user story is defined. Both situations are bad. In the first situation, the team doesn't have enough details to create a solution. In the second situation, the product owner and business loose all overview on the functionality which is lost in all the details.

As a developer, tester, project manager, product owner or whoever I want... The user story format is meant to make clear what you'll need to deliver to the end user and what the business value is. But in reality, you'll have to do other work as well to make it possible. That's why, I've seen a lot of user stories that starts of with project roles. Again, because of the user story mantra and because no other way is allowed to define work that needs to be done. There is only the backlog that consists of user stories. Soon, the backlog is a mess that consists of a mix of value driven user stories (that hopefully the business understands) and a lot of technical stories and side issues (that the business definitely doesn't understand). So what happens? The business tunes out and the backlog is only an IT thingy again and project management will make their own rapports. You will loose the power of Agile Scrum, which is meant to get the business back onboard IT projects.

Mix up what you want and how it is solved Product Owners, functional designers, requirement managers, etc put solutions in the user story. So, the format changes from: "As a who I want what because why" to: "As a who I want how because why". A subtle difference, but an important one. For a simple example, look at the following user story:

As a I want to see a table with columns a, b, c... to display transactions with paging on every 20 rows because I want to be able to see all of my transactions to have a clear overview of my bank account.

So now the team must implement a table with paging. Not a lot of room to manoeuvre. But what about showing the data on a mobile screen and loose some columns due to smaller screen sizes or maybe a tile orcard display type works much better in this situation. All considerations on how to implement the functionality, not what functionality. A user story focussed on what is needed could look something like this:

As a I want to have all the insight in all of my transactions because I want to be able to see all of my transactions to have a clear overview of my bank account.

Now there is room for the team to think of different implementations. The story is focussed on what to accomplish. Not on how to accomplish the functionality. The team can design and try out different solutions and see what works best, do some user testing and make different choices. All valid implementations on what needs to be implemented. But wait, now the team looses the possibility to describe the implementation details, because they don't fit in the user story anymore. So, the process to try to put the what and how both in the same user story is hard and confusing. In reality, you always loose one or the other.

Solution, separate the what and how

I like the user story format. The reason behind why user stories were introduced is good. Focus on the business value is a good thing. Years ago, IT seemed to have lost that focus. It's good that this focus is back. So how to deal with the backlog issues I mentioned above? Well, you'll need to separate the what from how. Make two backlogs, one that concentrates on business value and what is needed for the customer to deliver that value. And the other one should focus on how to design and implement that functionality together with details needed to implement. The first describes the what and the why and the second describes the how.

In Lerni the first value driven backlog is based on ideas. In Lerni you can describe for who the ideas is meant and what is delivered to this persona and why this idea is a good idea. Does it solve a pain, automate something for the persona or fulfill a dream the persona has? So what is the value of the idea? This is a good basis for an idea backlog that can be communicated with the business. An idea backlog has no solution in it, but only focusses on how to deliver added value to customers. This backlog can be used for discussions on the level between different stakeholders of the project. For example, the product owner can discuss with project management and other business stakeholders.

The user story backlog in Lerni is focussed on how to implement an idea. Each idea is implemented in a series of user stories that describe concrete scenario's implementing an idea. So every piece of functionality is described in a user story, that is very concrete and testable. This is the backlog for the team and its product owner. It is concrete and describes how ideas are implemented. So every user story has a direct relationship with the idea that is implemented.

Conclusion

By separating the concerns of what and how, you can achieve the essence of Agile Scrum. Focus on business value and prioritize the work based on just that. The idea backlog is used to discuss value between the business, product owners, product managers, marketing department, program managers, etc. Here the choices are made based on added value. Prioritizing the idea backlog it will steer the Scrum process based on value and value alone. The user story backlog is used by everyone involved in implementing the product: among others the product owner, user experiencers, designers, developers, testers, etc. All details needed to create a good product have a defined place. As a bonus, because of the direct connection to ideas, a lot of context is given to the implementation team. This helps in making the right decisions during implementation by the team.

If you also have an opinion on this subject, please comment or contact me. I would like to get in touch to have a chat.

Lieuwe van Brug

Founder

Agile architect, coach, scrum master and developer with a lot of years of experience in different combination roles. Passionate in making ideas a reality. Good ideas and a good open environment with the right people make the impossible, possible. Creativity, the right technology and an open team spirit are perfect to get it done in this time of innovation.

About Us

It doesn't matter if you're offering a product or a service, continuous learning and being agile is the only way forward. That's what Lerni stands for and it wants to help you capture all ideas and use them efficiently on a day to day basis.