User stories are the way to express the requirements for the product which then become part of the backlog. User stories are the medium to showcase what needs to be done in a very simple manner. In Agile user stories are smallest unit of the work that needs to be done to obtain a certain business value.
User stories are crisp and understandable and hence harmonise very well with the agile concepts which encourages to break big chunks of work into smaller and workable units.
User story format
Format of user story should comprise of three things:
- For Whom the work needs to be done.
- What work needs to be done.
- Benefit of doing this work.
Let us now put this format building points together
As a < For whom the work needs to be > I want to < What work needs to be done > so that < Benefit of doing this work>
User story sample
Let us see a sample to enhance our understanding on user stories. This is an example of a user story for clinicians who want to view the lab results of their patients to be marked in red if the results are out of range so that they get alerted as soon as they see red results on screen.
As a clinician I want to view the results of the patients marked in red if the specimen results are out of range so that it gives an alert that results are not appropriate.
User story writing
User story writing forms an important part of your project as the stories written correctly save a lot of time, plunges in conversations and thus help in moulding your backlog in right shape. User stories form the core of agile projects.
Ron Jeffries offered an effective way to write user stories, which is also called as a 3 C’s principle.The three Cs comprises of Card, Conversation and Confirmation.
- Card: Card here symbolizes that a user story should be small enough to be expressed on a small 3 x5 inch card yet effective. User stories should be written such that they are able to hold the essence of the requirement in simple words.
- Conversation: Once the user story is written these user stories are then opened to have more discussions, conversations around these requirements. Many meetings like backlog grooming, sprint and release planning meetings form the stage for these conversations and information exchange. The focus is to have more of on going conversations and less of detailing the requirements upfront.
- Confirmation: This ‘C’ is to build user story acceptance criteria that is what are the conditions to satisfy the user or product owner that this story is completed. Many teams also have the acceptance criteria to be fulfilled as their definition of done. These are the conditions of contentment and on the user story card, they can be written on the backside. Confirmation should be part of the user story for example in the above user story of results the confirmation can be :
- The results marked in red should be on all pages of software where results are shown.
- The results should be shown red on both the desktop and mobile versions of software.
User story INVEST
INVEST is one method to write good user stories, this criterion was offered by Bill Wake which says that we can say the user story is well written if it follows the INVEST rule.
I’: Independent – Try to write your stories which are independent of each other that is one story should not have the dependency on the other stories and whenever required can be pulled and worked upon. There are times when sometimes it is not possible to have a story completely independent and that is ok but the idea here is to minimise the dependencies.
‘N’: Negotiable – User stories should have a basis to be negotiated in terms of details. User story holds the crux of the requirement and should be open to be negotiated with product owner or end user. The product owner can specify the requirements and the team then decide on how to work on it based on the negotiations they do.
‘V’ : Valuable – No user story should be considered appropriate for working unless it adds some value to the business. The more the user story adds value to end user and customer the more priority is given to the user story.
‘E’ : Estimable – User stories should be such that the team is able to do some kind of estimation to those.Therefore keeping the user stories a small unit of work makes them easier to be estimated easily. If the atomicity of the user story is maintained it is very convenient for the team to pull it. There is no point of writing a user story which cannot be estimated.
‘S’ : Small – User stories should be sized appropriately that is they should be small in size to be worked upon. For example, if we are working in scrum agile methodology then the scrum duration is generally 2-3 weeks therefore the user story should be small enough to be completed in days.
‘T’: Testable – All user stories should have a test criteria , how can we say that the user story is done or not done if we are not able to test it. After the competition of each user story the team should able test it and determine if the user story has been implemented successfully or not. There should be a clear Yes or No after the testing is completed.
User story scrum
In Scrum, user stories are contoured properly , below are few points which depict how well user stories dovetails with scrum.
- Product Backlog comprises of user stories, epics and themes.
- Sprint Backlog consists of user stories.
- Backlog Grooming sessions are used to divide Epics (bigger stories) into smaller manageable units of work called user stories.
- Sprint planning are used to discuss more on user stories to add details, decide the definition of done (acceptance criteria), priority and if they will be worked on the upcoming sprint.
- During the sprint planning meetings these stories are estimated.
- One of the most popular estimating technique in agile scrum is planning poker where each user story is estimated and a mutually agreed story point is provided to the story.
- Scrum also uses story mapping technique : a visual representation of the product backlog using these user stories to get a bigger picture of your product.
Summary
User stories are smallest unit of work in agile , they should follow a certain format when written and should have a criteria to be estimated and tested.
