CodePattern.net

Overview:

This article deals with, what actually is a User Story and how an ideal User Story looks like.

Introduction:

This post is to share my experience on User Story writing and what all is needed to be identified before writing an User Story.

In traditional water fall methodology the requirements were in the form of lengthy SRS, PRD , Technical Documents, DB diagrams, Flowcharts, Usability requirements documents, Integration Documents, Performance requirements, Legal Compliance Documents, Security requirements and many more.  To go through all these requirements a huge number of members i.e. BA, SME’s , DBA, Legal Experts and many more depending upon the requirement are hired. Once these requirements are finalized  the plans are created.

This all only takes lots of time, effort, and investment but also there are ample chances that the requirement may change in future depending on some external influence.

To overcome  such lengthy requirement to be first analyzed and then create documents for them, it is broken into business values and from customer’s perspective. Such broken pieces are called User Stories.

So a user story represents a small piece of business value that a team can deliver in an iteration.  In other words they are a simple way of describing and tracking project requirements.  It describes user observable features the system needs to provide. It keeps focused on delivering value to end users, rather than focus on internal tasks. It is short, simple description of a feature using everyday language. It is generally prioritized by the customer.

How does a User Story look like?

A User story is written from the user’s perspective. It generally doesn’t specify implantation. Stories should not be big enough to take longer than a single sprint to complete.
So a general format of a User Story looks like.

Where,

• - ABC denotes the User for whom the Story deliver value for
• - LMN denotes needs of z (ABC)
• - And XYZ is the business value derived from meeting this need to the customer.

Few examples-

• As an END USER I want to login to my website to check by EMAILS.
• As a traveler, I want web check-in so that I save my time at the airport.

INVEST in User Story

Different Product Owners (PO) write user Story in different fashion. I want to draw focus on what all is taken into consideration while writing a User Story or precisely the art of User Story writing.

The art of writing a user Story comes from knowing INVEST

• - Independent:

  The basic art of writing a story is that all stories should be independent. This is inspite of the fact that they are derived from the requirement which generally are highly interrelated and all stories should combine together to generate the deliverables. The reason for the stories to be independent is that the team can pick any story in the sprint planning depending upon the capacity.

• - Negotiable:

  User story should be negotiable. It should avoid too much detail and should keep it flexible so the team can adjust how much of the story to implement

• - Valuable:

  User Story should generate some value to the desired product. Ideally it is not recommended to have a technical story.

• - Estimable:

  Another Characteristic of a User Story is that it can be estimable. The team should be able to size the story and estimate if it is possible to complete it within the iteration cycle. Estimates are based on the historical observation along with time, complexity and effort.

• - Small:

  It should be small enough to be fit into a sprint. It is recommended that if a story is not seems to be fit into a sprint should be further broken into to fit within the timeline.

• - Testable:

  The last but not the least to note that the story should be testable. It should have some functionality to be delivered and so it can be verified before it is reviewed in the demo.

Apart of the above few things to take care for a User story are-

1. It should have an acceptance criteria
2. It should have a priority list
3. It should not have gold plating
4. Not too many details
5. Too small
6. May attach light weight documentation for better understanding.
7. It should cover the entire layer of the application in a story rather than separate story for every layer of application.

Conclusion:

Today most organization is switching towards Scrum and creating User story are the way of handling requirements in the Scrum framework. So writing a good quality User Story resolves many ambiguities. So it would be good if these qualities are inculcated.