As you probably already know, among the values and principles promoted by Agile approaches, there is collaboration; that is, collaboration between the various contributors who take part in the development, marketing, and use of the product.
Although user stories are way too often overlooked and misunderstood, they play a critical role in a development team and, more broadly, in the team responsible for the product in its entirety. They aim to start discussions about the user needs. Therefore, they foster collective intelligence as well as innovation in order to find the best solution.
User stories also allow to understand the reason for our work. We wish to deepen the commitment of those involved in the project and increase their accountability regarding the product.
No user story is perfect. As previously indicated, the user story is used to initiate discussions and encourage collaboration. The team has to identify and understand the actual user needs. And certain principles may facilitate discussions:
A. Like any good script, the user story is about a single clearly identified actor. Personas are often used to develop empathy for the user.
B. A user story describes a requirement, not a function. The latter is the discussion’s output, not its input.
C. A user story indicates the benefit the user will gain if the need is filled. It allows to set the context and it helps the team discuss about the value of work.
Please remember that each team may use a visual support of their own. To ease story management, the title may be a short description of the story, but the full description is also required.
The first three elements are covered in the following typical template:
As a <role>, I want <goal/desire> so that <benefit>.
D. A user story is independent from other stories. It is conceptually autonomous and it expresses the incremental nature of the approach.
There are two instances regularly found in product backlogs. The first is when development is done in silos; i.e., there are stories for the integrator, stories for the designer, and stories the developer. Ideally, silos must be broken down. Therefore, a story should cover the complete work to be done to meet a business requirement.
Thus, the following user story does not allow for a fruitful discussion about the user’s need:
As John, the user, I want an interface to perform an action.
The second instance is more subtle. It is based on preconceptions. For example, we often think that an object needs to be created first to be able to modify it. However, a simple addition to the database would free us from this constraint and allow us to prioritize the modification of the object when the business value requires it.
This topic is covered in this post about dependency between stories.
E. The user story is about a need for which the team negotiates a solution.
As John, the user, I want a red “Buy” button (#ff0000) at the bottom of the product page in order to be able to buy it.
With such a story, the team cannot negotiate a solution. In fact, the story is expressing the solution rather than the need. The team can do the work, but they will rapidly lose their product engagement and will never feel accountable for the business value.
F. The value of a user story must constantly be questioned.
As John, the user, I want the MP3 list in order to display the songs I have.
In this instance, is there value for John to see the songs he possesses? By questioning this value, we could learn that John is seeking a specific song for which he does not know the title while he knows the band’s name. Discussions could then take a completely different turn.
G. The user story must be testable. Thus, we must be able to quickly verify whether the need is being met or not. Stories with qualifiers such as “faster” or “nicer” are very subjective and hinder discussion. Such stories often hide requirements that are non-functional and that need to be discussed.
H. The smaller the user story, the greater the chances are that the need will be understood and the solution will meet the need.
As John, the user, I want to buy a book in order to educate myself.
In the instance above, it is difficult to meet the requirement because it is so big. It is therefore considered an epic. It will have to be broken down into smaller requirements.
I. It is possible to estimate user stories. If we are not able to estimate a user story, it indicates that we do not control the requirement or solution. In both cases, discussions must be maintained. It is quite possible that we will introduce an investigation in the product backlog in order to validate a business or technological assumption.
Conclusion
The quality of a user story is related to the quality of the discussions. In fact, it will directly affect the team’s capacity to properly meet the user requirements.
By clearly distinguishing the what and how of user stories, we allow developers to unleash their talent and creativity, thus collectively finding the best way to do things.
I hope this blog post has enlightened you regarding the importance of user stories. They foster greater collaboration within the project team and help understand the criticality of their interactions.
References
These elements are partly from the INVEST standard described by Bill Wake regarding SMART goals.
For more details on how to write user stories, refer to Mike Cohn’s following book: User Stories Applied: For Agile Software Development.
No Comment