User Stories applied guide in agile scrum, User Story best practices

User Story is an Agile software development methodology tool which helps to capture a description of a software feature from the perspective of end-user. User Story help to create requirement description.

User Story describes three things:

• Type of user
• What user wants?
• Why user wants?

In Agile software development User Story is a description which consists of one or more sentences from end-users or the system users which captures that what a user does or what s/he needs.

Writing User Stories, Examples and Templates In Agile Methodologies

1. User Story Template

User Stories are written by product owner or on the basis of end users feedback. User Story template is a good guide for end users. It helps, in are creating User Story. User Story template helps them to write User Story in a selected pattern.

Note: Agile does not force any User Story template.

2. Use Cases

Use Cases are the list of actions to achieve a specific goal. In Agile mostly business related persons think that User Story and Use Cases are same.

Are they really same?

The answer is no. Because User Story is a requirement by end user in short and simple words. Any non-technical person can write a User Story but Use Cases are written by technical experts. In other words we can say that User Story is a simple shape of requirements while, in Use Case requirements are written precisely.

2.1 Use Case Example

User Story: Responsive website for a sales company.

Use Cases:

• Responsive website
• Sales record features for buy and sell
• Calculate daily income, profit, loss
• Monthly Target report
• Employees Record Etc.

2.2 Use Case Actors

Actor is a user or any system who interacts with product. Use Case actor is a stakeholder of product but not all stakeholders are actors in Use Case.
Two kind of actors are discussed in Alistair Cockburn’s book “Writing Effective Use Cases” .

2.2.1 Primary Actor

“The primary actor of a Use Case is the stakeholder that calls on the system to deliver one of its services. It has a goal with respect to the system – one that can be satisfied by its operation. The primary actor is often, but not always, the actor who triggers the Use Case”.

2.2.2 Supporting Actor

“A supporting actor in a Use Case in an external actor that provides a service to the system under design. It might be a high-speed printer, a web service, or humans that have to do some research and get back to us”.

2.3 Example

Use Case Name: Workflow Chart
Primary Actor: Product Owner
Secondary Actors: Software Development Company

3. Epic

A perfect User Story needs to be small enough so that developers can develop it in an iteration. Agile User Stories benefit is that they are written at varying detail level. A User Story can cover a large amount of functionality. When a User Story is too large then it becomes an Epic.

Examples:

Here are some examples of epic
User Stories examples.

• As a user, I want to get a backup of my entire hard drive.
• As a user, I want to scan my entire hard drive so that i can find a specific file or folder.
• As a user, I want an app so i can save my daily routine work.

An epic is too large for agile team to complete it in one iteration, therefore scrum team split epics into multiple User Stories before working on it. Some time epics are splitted into dozens or even hundreds of User Stories.

Agile User Stories and Groomed Product Backlog

4. User Story Qualities

Qualities of User Stories	Syntactic Well-formed Automatic Minimal Semantic Conceptually Sound Problem Oriented Unambiguous Conflict-free Pragmatic Full sentence estimate-able Unique Uniform Independent Complete

User Story Characteristics in agile scrum methodology

5. User Story 3C Method

Every User Story has three critical aspects. In Agile, this method is known as 3c of the User Story. Which are:

• Card
• Conversation
• Confirmation

Ron Jeffries is the father of 3c technique. He is one of the three founders of the XP (Extreme Programming) software development methodology circa 1996, along with Kent Beck and Ward Cunningham.

User Story Card	(A brief, simple requirement statement from the perspective of the user)	User Stories are written on cards. Cards just have some text, which helps Agile team to identify the requirement, And help team to remind that, what the story is? These cards do not contain all information about requirements. These User Stories cards are just like tokens which represent the requirements. These cards are helpful to do effective planning. Notes about requirements, Priorities and costs are written on it. These cards are handed to the programmers when they schedule the implementation of the User Story, and these cards are also given back to the customers after the completion of the User Story.
User Story Conversation	(A story is an invitation for the conversation)	Conversation is verbal generally, But can be documented if need. Best augments are good examples, and the best examples are executable examples. Executable examples are also called confirmation. Requirement itself is a communication between customer and developer through conversation with: Exchange of Thoughts Feelings Opinions This User Story conversation is taking place between customer and programmer when: Story is estimated (Mostly during the release planning) Story is scheduled for implementation (In Iteration planning meeting)
User Story Confirmation	(Each story should have acceptance criteria)	We are never certain about the program until we passed the acceptance test. When the User Story is done, then programmers implement the acceptance test also. Every Agile team can process this step in different ways. Some teams have tools that let the customers in to test the program, while some teams have QA/Testers who done this job. An Acceptance test is get done, at the end of an iteration, When the User Story is done, programmers show customers that User Story is done, and acceptance test is running correctly. Confirmation is a green signal from customer or product owner. A lot of spreadsheets of calculations, layouts, sketches even lot of multi-page documents look like the conventional method, but it is also useful method in some rare cases.

5.1 Ron Jeffries said:

Looking back over the years I have almost never found this kind of document to be ideal.

Nowadays! For an ideal program development even for the complex situations 3c method is considered better than any other conventional method. 3c is a fast technique which never slows down your process.

6. User Story Estimation

Before you start your work, scrum team should must know that how large it is. Estimation of User Story is very important for scrum it make software production easy, but User Story estimation is really hard. There are few thing which help a lot in User Story estimation.

Keep estimates manageable: Try your best to keep most or atleast most important estimates within an order of magnitude (such as 1 to 10). For example, poker cards are between 1 to 13 but we estimate cards in a well sequence range. Which makes estimation easy.
Estimate in Relative Terms: Estimate your work in relative term rather than absolute term. Instead of saying that this work will take 10 days, say that this work will take time as long as that work which we worked on previously in that session. With this method team does not need to think about sub steps of working, they just find similar pattern and and use the same estimate.
Bucket Backlog Items by Story Size: It is extremely hard to estimate User Stories precisely. Scrum team estimate bucket backlog items by their story size, for this purpose team might choose an estimate using 1, 2, 4, 8 and 16 method or Fibonacci sequence 1, 2, 3, 5, 8 and 13.

7. User Story Mapping

Software development is a complex procedure. There are possibilities that a small mistake can result in failure of product development. For a better output in Agile we also focus on User Stories to make our development procedure free from mistakes. For this purpose scrum master arranges the User Stories in a useful sequence for better execution.

Essential Skills for Every Scrum Master

User Story mapping is a valuable technique of arranging User Stories in a useful model to understand the system functionality, identify omissions and cracks in backlog. User Story mapping is a visual way of building product backlog.

7.1 User Story Map Structure

In Agile development procedure User Story mapping does not start from an overarching vision.
Vision is achieved from goals. Goals are achieved from completing activities. Activities are further categorized in Tasks and Tasks are transformed into user stories.

Goals > Activities > Tasks > Stories

7.2 Story Mapping Advantages

• User story mapping helps us to understand the structure of user story.
• It explains that how each part of User Story is related to the other.
• Story mapping also helps to prioritize User Stories.
• It brings all stakeholders on the same page with visual presentation of the product backlog.
• Story map can be transformed into an Agile project management tool like Mingle, Trello, Jira as Product Backlog.

7.3 Related Guide Book

Get Book

Jeff Patton has over 20 years of product design and development experience. He helps companies to create great products. Jeff is a Certified Scrum trainer, and winner of the Agile Alliance’s 2007 from Gordon Pask Award for contributions to Agile Development.

7.3.1 Description

This book explains you, how changeable story maps enables the team to hold better conversations about the project, throughout the Agile development process. Your team will learn, how to come away with a shared understanding of what you’re attempting to build and why.

Top Books To Write Good User Stories in Agile Scrum Methodology

User Story mapping is a valuable tool for Agile software development. This insightful book explains how this often misunderstood technique can help your team to stay focused on users and their needs without getting lost in the enthusiasm for individual product features.

8. DoD (Definition of Done)

Every scrum team has different definition of done. DoD describes the work quality and helps in assessment of User Story completion. DoD need to be enforced by scrum master during the sprint, Scrum Master makes sure that the team put the focus in the right activity, and in the end, they produce the product which is “shippable“.

Using Definition of Done (DoD) to ensure best scrum deliverables

9. User Story Acceptance Criteria

Acceptance Criteria and Conditions of Satisfaction are used interchangeably. Every User Story is accepted when it passes the acceptance criteria. Acceptance criteria is a list of parameters, which define the quality of User Story.

Acceptance Criteria provides a detailed scope of requirements which helps the team to understand User Story requirements and values, further team can slice User Story easily.

Who writes Acceptance Criteria?

Product owner is the person who is responsible for acceptance criteria. He defines acceptance criteria according to his need. After the development of product, product owner checks the acceptance criteria checklist to accept or reject the product.

Example of User Story Acceptance Criteria

Acceptance Criteria could include:

• Coloring and styling of product
• Information can be stored in database
• Email confirmation
• Words Limit (Min. and Max.)
• Required Features in current User Stories