The most fundamental need of any project team is to know what to deliver. This goes no matter if you are doing a traditional waterfall project or a Scrum project. If you build something no one wants, you have wasted your time.
In waterfall projects, the needs of the customer are usually specified in a big Requirement Specification, where great efforts have been invested in making it as complete as possible. This makes it an expensive and time-consuming process – and as a “bonus”, it is very hard to change.
In Scrum, we use the Product Backlog instead, and in my world, the Product Backlog contains User Stories. The benefits of User Stories are that they focus on people instead of the system; they allow end users to understand what they will be getting, while being easy to maintain and change.
The definition of a User Story
Many people have a limited understanding of what defines a User Story (or at least a good one). I have experienced Product Owners who believe that a User Story is simply a statement of the following syntax:
As a <type of user> I want to <have something> in order to <realize these benefits>
However, anyone who has tried to align expectations based on just the above statements will know how impossible that is. No one has the same understanding of those one-liners, and the differences in expectations are not only “small details”, but fundamental misunderstandings.
Here is an example of a User Story, which highlights some major differences:
As the <US Government>, I want to <ease transportation between different offices> in order to <increase productivity at NASA>
If we try to interpret that User Story based only on the Card we can end up in very different places:
- We need 20 corporate jets fully equipped with technology and relaxation facilities.
Time to deliver: 2+ years
- We need a car to commute between different offices in Houston.
Time to deliver: 1 month
- We need a bicycle to get faster between the different Buildings at Houston Space Center.
Time to deliver: 2 hours
In order to increase the understanding of the User Story, you will have to Invest a lot more in making it meaningful – and thereby helping the team succeed.
It is my experience that you get the best results if you follow the three C’s of User Stories – Card, Conversation and Confirmation (Thanks to Gorm :)).
The Card you have already seen, so I will focus on the other two C’s.
It is never a good idea to align expectations in writing alone. If you look through the history of waterfall projects, the evidence is clear. You either get something you cannot use, you end up asking for (and getting) a lot you do not need, or (as in most cases) you will probably end up with a combination of the two, where you get something that is “kind of working”, and pay for a lot you do not need.
User Stories place great focus on understanding what the users actually need; and less focus on contractual documentation of the hardcore deliveries. It is therefore important for the Product Owner not only to write the Card, but also to invest time and effort in understanding the business needs.
The focus of Conversation is to ensure a relevant dialogue between the Product Owner and the Team. For this purpose, I usually find the following form useful:
- The Product Owner gives a brief introduction of the User Story to the Team
- The Team asks questions and suggests alternate solutions
- The Product Owner and Team agrees on what the User Story means.
Based on the discussions with the Development team, Project Sponsor and other relevant stakeholders, the Product Owner will then be able to establish actual Accept Criterias and use them to confirm expectations. By documenting the Accept Criterias along with the high level expectations, you will be able to limit fuctuating understandings.
I hope you have found the article interesting, and look forward to hearing from you.