Skip to main content

User Story In Agile Scrum - By Ankur Mistry

In this article, we will learn what User Story is and how to write one. User Story plays a major role here. It is the part of the Agile process where instead of writing comprehensive requirements, we write a short description of a feature.
As the Agile Manifesto says 'Working Software' Over 'Comprehensive Documents'.
What is User Story?
User Story is a short and simple description of the feature or requirements of the project. Generally, user stories are written on sticky notes or index cards as a user or role-based perspective.
User Story Template
As a < type of user or role >, I want < some goal > so that < some reason >.
The template identifies 3 questions - "Who", "What", and "Why". If the team doesn't know these three answers, it means they don't understand the story, and if they don't understand the story, then it's difficult to split it well.
 
Reference:https://mazoea.wordpress.com/agile/ 
In the above card, you can see the format. Each story has a Story Id, Story Title, Format, Acceptance Criteria, Priority, and Estimate points to complete the task.
The 3 Cs of Story
  • Card - User stories are written on the Card, just having enough description of the requirement. 
  • Conversation - Stories must be conversational, i.e., a collaborative conversation facilitated by the Product Owner with the team. This is an in-person conversation.
  • Confirmation (Acceptance Criteria) - The acceptance criteria is used to determine when the user story has met the goal of the user.
A good user story uses the “INVEST” model.

  • Independent - Reduced dependencies so easier to plan
  • Negotiable - Collaborative effort for detailing 
  • Valuable - Provides value to the customer and business
  • Estimable - Small enough and split well for team to estimate
  • Small Enough - Can be completed in less than a week by the team
  • Testable - Good acceptance criteria

User Story Example
As a User, I want to be able to enter my personal information for registration, so that I can register and browse my web application dashboard.

Acceptance criteria
  • The user needs to enter the data for mandatory fields, identified by *(asterisks).
  • A user needs to enter a valid email ID and mobile number.
  • If the user clicks "Save," then the data should be saved in the tables with a success message.
  • If the user clicks "Reset," the data entered by him/her is refreshed and the fields are cleared.
Summary

User stories are not high-level documents because, in agile development, documentation is not compulsory. A user story is a collaborated effort intention of which is to foster the collaboration.
Reference
  • https://www.scrumalliance.org/community/articles/2010/april/new-to-user-stories
  • https://www.mountaingoatsoftware.com/agile/user-stories
  • https://www.scrumalliance.org/community/articles/2012/april/an-argument-for-comprehensive-user-stories

Comments

Post a Comment

Popular posts from this blog

Agile Story Point Estimation Techniques - T-Shirt Sizing by - Ankur Mistry

In my previous articles, we have discussed  Agile Story Point Estimation  and  Agile Story Point Estimation Techniques - Planning Poker . In this article, we will learn Story Point Estimation using T-Shirt Size Technique. What is T-shirt sizing? T-shirt Sizing is one of the Story points sizing technique to estimate user story usually used in agile projects. It's a relative Estimation Technique. Rather than using a number of planning pokers, here, Items are classified into t-shirt sizes: XS, S, M, L, XL. The term originates from the way T-shirt sizes are indicated in the US. Rather than having T-shirts in sizes 4, 5, 6 etc, there are just a few sizes: Small (S), Medium (M), Large (L) and Extra Large (XL) and so on. With T-shirt measuring, the development team is made a request to evaluate whether they think a story is extra-small, small, medium, large, extra-large, or double extra-large. By expelling the numerical score, the development team is allow...
Post a Comment
Read more

Retrospective Meetings By:Namrata Parik

This article talks about the least important meeting in a Sprint, the retrospective meeting, at  least as considered by the business and sometimes also by the developers. It is often considered to be a waste of time and given the least priority, and sometimes even omitted if there are time constraints. In fact it is the most important meeting but does not show any immediate business value. Talking about my own experience, we were newly into the project and the geek in the team was not getting enough technical tasks to devour, resulting in not so good documentations by him and his general disinterest in the team. This was discussed in the retrospective and his problem was faced, assessed and solved within a span of two weeks (a single Sprint), and he was given enough tasks to fulfill his coding appetite, resulting in better output by the entire team. Talking about retrospective techniques, the most effective way to conduct a retrospective is the Timeline Review. The te...
Post a Comment
Read more