INTRODUCTION

Good user stories are a key element in the Agile methodology – It is from the US that we define the functionalities of the application that we are building. The agile methodology. is based on the principle that the specifications of a project should be easily understandable and maintainable. The purist waterfall model had an extremely complex specification model:IEEE ANSI 830 (1993, Rev 1998).

The principles of agile development changed this practice in favor of the user stories. The US is not as exhaustive as the classic requirements, but they offer information that makes much more sense, since good user stories define functionality. 

What is a User Story?
A user story is a part of an agile software development approach to present the details of a requirement from a customer’s point of view. A user story specifies what type of user you are, what you want and the reason behind it. A user story helps to create a simple and short description of a requirement told from the user’s perspective.

They generally follow a simple approach for a user story:

As a < type of user >, I want < a goal > so that < a reason >.

Another approach includes:

As a, I want because.

Originally, agile user stories were meant to be very short and simple to write on sticky notes or index cards. They were fixed on tables or walls to simplify their planning and discussions. Therefore, they actively shift the target from writing about features to explaining them. In reality, these explanations are more important than the story is written. We can know them particularly in any major agile process.

Characteristics of user stories

  • A good user story is written in one to three lines
  • A good story should always be in the active voice
  • User stories are used to communicate. So make them visible and accessible

Tips for writing good user stories

  1. Keep your user stories clear and concise
  2. Write user stories collaboratively
  3. Start with Epics
  4. Refine the stories until they are ready
  5. How to Write a High-Quality User Story
  6. A good practice to make sure the User Story is of proper quality is to adhere to the criteria of Bill Wake’s INVEST acronym. INVEST also helps to determine whether the User Story is well understood and ready for the development team to start working on it.
  7. Independent – the User Story should not depend on another User Story, so User Stories can be developed in any sequence.
  8. Negotiable – details of the User Story are negotiated in a verbal conversation between the Product Owner and the development team.
  9. Valuable – the User Story should bring needed value to the user/customer.
  10. Estimable – the User Story should be understood well enough by the development team to estimate it.
  11. Small– the User Story should be small enough to fit in iteration.
  12. Testable – proper acceptance criteria should be written for the User Story, so it can be validated.

What is Not a User Story?

Let’s be honest with ourselves: the User Story cannot be a “technical User Story” by its definition, as in such a case it will not bring direct value to the user/customer. Still, lots of teams like to create User Stories when they need to do some technical task like code refactoring. I recommend using other work products for such tasks, and agreeing on this type of work with your Product Owner for him to see why it is necessary. The same relates to nonfunctional requirements tasks, interface design tasks, complex user interaction tasks, or bugs. You are free to create other work products for these tasks. For example, a limitation Story may be used to represent nonfunctional requirements. The User Story is a great technique to capture product functionality, but we are not obliged to use it for all purposes.

Who is Responsible for Writing a User Story?

Generally, customer representative such as a Product Owner is responsible for User Stories. Anyway, User Stories are not specifications given from the top level to the team, but more a collaboration technique between the Product Owner and the team. That’s why it is better if User Stories are written collaboratively. A great way to do this is a story-writing workshop.

How Do You Know When a User Story is done?

Use the Definition of Done technique. Simply put, Definition of Done is as a shared understanding between team members of what it means for work to be complete. Definition of Done is usually created in the form of the checklist of activities, which demonstrates agreed value. Teams sometimes neglect the last one, what can make the User Story not potentially shippable to the customer at the end of iteration. Definition of Done technique helps to avoid this.

Example of Definition of Done:

  • Unit tests are passed
  • Code is peer-reviewed
  • User acceptance tests are passed
  • Integration tests are passed
  • Regression tests are passed
  • User guide is updated

INVEST in good user stories

Writing requirements in User story format was a practice first adopted in Xtreme Programming. This was a part of involving the end users early and getting their perspective of what has to be developed. In 1998 Alistair Cockburn visited the Chrysler C3 project in Detroit and coined the phrase “A user story is a promise for a conversation.” It is a business statement of what is needed and why. However for the user stories to become effective it is also important that they follow some best practices so that the business and development teams have a common guideline.
These guidelines are referred to as the INVEST criteria, where INVEST is an acronym for:

  • “I” independent (of all others) – The story can be worked on independently and shown to the end user – all dependencies are completed and no longer a blocker
  • “N” negotiable (not a specific contract for features) – Stories should be the starting point for conversation and they should not be treated like a contract negotiable.
  • “V” valuable (contract negotiable or vertical) – They should provide value to the end user. 
  • “E” estimable (to a good approximation) – Only stories which are clear can be estimated, and in agile estimation are the best understanding guess based on the relative size.
  • “S” small (so as to fit within an iteration) – Story should be sized appropriately. They should not be too small or too the big.
  • “T” testable (in principle, even if there isn’t a test for it yet) – If there is a value expected from the story it should be testable and validated as delivered stable.

Why do other requirements still exist if this is so good?

  • User stories are starters for conversation and so they are preferred in projects where the Product owner is available for discussion. When the presence of a business member is not possible for the team all through the sprints, it could be difficult to have User stories as requirements.
  • User stories do not tell you how to develop – They just tell you what and why. If the team is new to the technology, user stories might not be good enough and the team would need a lot of support and guidance from experts to start the implementation.
  • Often user stories are misunderstood as being flexible even during implementation and team implement more than documented- unless guided well the technical implementation could be impacted.
  • Sometimes writing a user story can be tricky and time-consuming. User stories have a simple single sentence template, and are supported by acceptance criteria – and the acceptance criteria could depending on the maturity of the team become a binder or be treated as a contract by the members making it extremely difficult for the person documenting them.

Conclusion

Agile projects have requirements documented as User stories and approved by the Product owners, and with a self-motivated team which is aware of the business goals working on them, User stories activate the right conversations leading to best designs.

Barghavi

Share