A Case for User Stories

17 April 2014


One of the basic principles of Agile development is customer involvement in the project. The customer or user of the software is the single entity that provides what every Agile development team should most seek: customer satisfaction. Customer satisfaction is what funds the project; it is what keeps the machinery going. Satisfied customers bring the cash, provide the backing to continue the project, and reward the development team for their efforts. The way to customer satisfaction starts with customer involvement.

Consequently, customer involvement is a key element of the Scrum framework. Scrum requires a set of top-ranked user stories, referred to as the product backlog, to start the development process. But where do these product backlog items (PBIs) come from? The answer is: They come from the user or customer. After all, user stories, or PBIs in Scrum, represent the set of functionalities or requirements users have for the system. User stories should be written by the users or by representatives of the users of the system. User stories should be written as an expression of a desired function. By doing so, users are expressing requirements in a way that is easy to capture and easy to understand by the development team. In addition to the desired functionality, a good user story includes the basic reason for the desired functionally.

To capture all of this, the user story should be written using the following format:

As X,
I need Y
so I can Z.

Where X is a system user role,
Y is the desired functionality,
and Z is the reason or benefit to X of getting Y.

For example:

As a student,
I need to see my mid-term grades
so I can gauge my progress.

A well-written user story clearly communicates the required user functionality. In this example, the user -- a student -- is expressing not only the need to access grades but also the desire to gauge progress. Stop and study the above user story once again. If it had been written as: "As a student, I need to see my mid-term grades," and the Y was without the Z, or the reason, a different solution might result. Probably a solution that would not have fully met the user's requirements. But because we know that the student wishes to gauge his or her progress, the team should be able to deliver a functionality that fully meets this customer need.

Some teams may place little importance and even ignore the Z part of the user story. Having the user express what benefit they expect to receive is very important. Many times I have seen that once a user expresses the Z, the Y may change or be eliminated altogether. In other words, there may be alternative or better function(s) -- alternative or better Y's -- to achieve the desired benefit Z. As Scrum practitioners, we should not forget or eliminate the Z in our user stories.

The Scrum framework keeps customers involved and asks them to express their requirements as user stories. While Scrum does not directly address the process of generating the PBIs, normally the product owner meets with the customer or group of customers and solicits user stories from them before the first sprint planning meeting. This is sometimes referred to as Sprint 0. The user story format provides the development team with a clear pathway to providing customer satisfaction. The user story gives the software designer and the software developer a clear understanding of that the customer wants. It also provides the tester with enough information to start developing test cases even before the first line of code is written. If the team has achieved such a level of maturity, the user story provides an excellent foundation for test-driven development -- or, if use cases are used or understood, even behavior-driven development. Few other expressions of the user's requirements provide the team with such great bases for each member to start the development effort.

The user story is an excellent mechanism by which a dialog with the client is established. User stories present us with the opportunity to start a conversation with the user about their requirements and their expectations. Most product owners ensure that user stories also include conditions of acceptance. Usually the product owner asks the user to express what they would like to see to consider this requirement met.

Please don't confuse this with the Definition of Done. The Definition of Done is a general set of tests applied to all user stories in a project. Conditions of acceptance are individualized conditions applied to specific user stories. The conditions of acceptance are used by developers and testers to develop unit and/or integration tests. Conditions of acceptance may include nonfunctional requirements. As a matter of fact, documenting nonfunctional requirements as a condition of acceptance is becoming a best practice in several large organizations.

A user story is a short, very exacting expression of a customer requirement expressed as functionality to be delivered by the development team -- a requirement request delivered as a small power-packet pill. We see the advantages of using user stories as a way to express user requirements. In lieu of long requirements documents, which are either constantly updated or forgotten altogether, the Scrum framework relies on user stories to express user requirements. Due to their simple structure, user stories become useful tools for the entire development team. Everyone, from the software designer to the tester, will be able to start working from Day One if they are provided with well-written user stories. This allows the team to achieve customer satisfaction.


Opinions represent those of the author and not of Scrum Alliance. The sharing of member-contributed content on this site does not imply endorsement of specific Scrum methods or practices beyond those taught by Scrum Alliance Certified Trainers and Coaches.



Article Rating

Current rating: 4 (1 ratings)

Comments

Carlos Monroy Nieblas, CSM, 4/21/2014 12:21:45 AM
Have, communicate, and understand User stories is the most decisive factor for the success of a project as they should reflect the user’s needs. The author’s proposal to split them in the 3 parts (Who, What and Why or X-Y-Z) make it easier to understand by non-technical people the information required, and the rest of the activities should be aligned toward them.

The explanation of the user story (named Z in the article) should be the base for the formulation of the acceptance criteria as well as the main objective of the test cases design (as we need to verify that the artifact is doing what the user is expecting to be done).

You must Login or Signup to comment.