User stories are one of the main format to record user needs in the Agile world. There is however a debate on the amount of information that should be available to the Scrum team before starting the sprint. In this article, Zuzi Šochová recommends to minimize the size of user stories and to define simple conditions of satisfaction instead of writing acceptance criteria.
Author: Zuzana “Zuzi” Šochová, http://sochova.cz/
The user story is one of the most common formats how to record product backlog items. It has specific format which forces people to focus on business value.
As a [user | role| persona]
I want to get [functionality]
So that I get [business value]
As an example of user story for my online beer store called “Berrer”, we can write the following:
As Jon (busy manager with no time)
I want to get beers selected by “Beerer”
So that I can impress my friends by variety of rare brands.
It shall give us three different information – Who, What, and Why – which must fit together and once you read it to someone, it shall create consistent story together. As you may have noticed, the user story looks at the functionality from the business perspective and is customer-centric (note that customers are all user, stakeholders, other teams, … ). We never define how exactly it shall be solved, but describe the business impact we want to achieve.
Writing acceptance criteria was never good idea
Having that definition, companies are often missing the place where to write the exact specification. But there is none. It is all about having a conversation. It should fit on a small index card. Having said that, teams are still fighting and try to keep it as close as possible to the traditional detailed specification. Adding details as acceptance criteria is one way to achieve this goal. They usually look as a checklist of all possible details you shall/shall not implement. This seems to be useful for teams who have limited understanding of business and product, but it is not. To give you an example of such acceptance criteria for the user story above, they can look like this:
* Beers from all continents
* At least one beer from Belgium
* Several small local breweries
* One light, dark, Ale, Pils
With these criteria, the development team is not involved in the story definition anymore. They just take those points one by one and implement them. If it is not working because we missed something, it is not their fault but they will blame the product owner. He shall have made the missing pieces part of the acceptance criteria. So let’s have a look to better solution.
Define conditions of satisfaction instead
As we said before, the user story is about having a conversation. It shall be simple, clear, and easy to remember. If you write it well so that it is small enough, there is no need for any additional information at the back side of the card. However sometimes you might find it useful to stress certain expected behavior or impact. In such cases, we turn the user story card and write conditions of satisfaction. For the above defined story, they might be:
Jon can impress his friends by selection of all different tastes of beer selected from micro-breweries across the world.
As a result, the team is now focusing on solving user problem instead of implementing what was defined before. The implementation usually starts with a conversation. How can we deliver more value with less effort? What is the minimal functionality we have to deliver? How can we address his needs? We need everyone involved, everyone interested and that everyone understand the overall business, personas, their needs and their dreams.
It might take a little bit longer at the beginning, but it is worth investing the effort as the committed team which is living by the product can always come up with better solution than a product owner.
Writing acceptance criteria is a legacy from the traditional software development world, while defining conditions of satisfaction is very Agile. Agile and Scrum are a mindset. If you have it, it doesn’t matter how you write your user stories because you already understand the fundamental difference. It is about value to be delivered to the customer, not about the effort, items delivery or velocity. If you don’t have this mindset, changing only the label will not help. You would have to significantly change the way you think about backlog items. This might be a very painful and long process where the user story format with conditions of satisfaction will help. I went through that change with several companies during Agile coaching and it was always worth of the effort. If you want to get bit more practice, I also teach this approach at CSPO (Certified Scrum Product Owner) classes.
About the Author
Zuzana “Zuzi” Šochová is an independent Agile coach and trainer and a Certified Scrum Trainer with more than fifteen years of experience in the IT industry. She started with Agile and Scrum back in 2005, when she was implementing Agile methods in the USA. From that time, she has been credited with Agile transformation and implementation for many companies and teams around the world. By creating and sustaining Agile leadership, Zuzi believes the worlds of work and life can be made happier and more successful. This article was originally published on http://agile-scrum.com/index.php/2016/11/02/user-story-as-a-card/ and is reproduced here with permission from Zuzana Šochová.