SOP.BA.2 – User Story Checklist

Version Control

When making changes, please take the following steps:

1. Record the new version number and date of the changes made (make sure to update the title of this task too)

2. Write a short summary of the changes you made. Make sure to specify the location of the changes made.

3. Copy/paste the exact changes you made into the document.

This is so that these changes can later be updated on our TalentLMS platform

Example (for GST Canon)

Version 1.0.1 (7/24/20)

- I edited the 'Overview" section of the "Functions and Users" task to fix a typo:

• The first thing you should have in mind is exactly what problems you are solving for your users. How does your software improve user productivity and quality of life?

Version 1.0 (7/9/20)

- Verified congruence with GSU

Version 1.0.1 (8/19/20)

- Modified SOP.BA.2.4 Manage Stories in a Sprint.

Version 1.0.2 (9/11/20)

- Split SOP.BA.2.3 into SOP.BA.2.3/2.4 and changed SOP.BA.2.4 to SOP.BA.2.5.

Introduction: This checklist provides guidance on writing 'mature' user stories to be worked on by scrum teams.

Audience: All Business Analysts.

What is a User Story?

Agile is a value-based development methodology, where all features of the product that can add value for the customer are recognized, prioritized, and developed based on customer needs. These valuable features are best described in users' own words. Hence, finding out who the users are is an important task. Once all users are recognized, requirements which add value for the user are written down in consideration of the needs of those specific users. Since those requirements keep users in mind, they are called User Stories.

Effective user stories express the needs of users and support effective communication and collaboration between product owners and scrum teams. They prompt communication that aids in understanding users and developing the right products.

The ability to write effective user stories enables teams to deliver the right products quickly. This unit provides several checklists for writing effective user stories.

Who writes these user stories? The Business Analysts do!

A user story usually has a title of this format:

As a ROLE I want a FEATURE so that I get a BENEFIT. This is then checked against ACCEPTANCE CRITERIA to understand whether or not it is DONE.

User

A user is the user of the system

• A manager
• A clerk
• A developer
• A librarian
• An owner etc.

It is important to specify the user early on, as the user story will revolve around the perspective and needs of the user.

Benefit

Benefit is the value a user will get from the system

• A manager can see the audit report in one click, which will save his/her time
• A clerk could search a report, which will save his/her time
• A librarian could search a book by category, through which he/she will improve customer service
• An owner can order a piece of equipment, which will save him from hassle

By writing the title in this way, it's easier for the reader to know who is getting what and to know that information helps at the time of prioritization, estimation, and development.

Acceptance Criteria defines how a particular feature could be used from an end user's perspective. It focuses on business value, establish the boundary of the feature's scope, and guides development. These are unique to a user story and form the basis of user story acceptance testing, which establishes the conditions for the success of the feature.

When the product owner verifies a particular user story acceptance criteria and the developed feature passes it, the development of the user story is considered a success.

When writing acceptance criteria, remember to keep it in basic language that cannot be misinterpreted.

If you are unsure of what to write, all you need to do is picture the boundaries of your user story and what must be true in order for a story to be confirmed as working as intended.

For instance, Sandy Mamoli states that this user story:

• As an <internet banking customer>, I want <to see a rolling balance for my everyday accounts> so that <I know the balance of my account after each transaction is applied>.

has the acceptance criteria of:

• The rolling balance is displayed
• The rolling balance is calculated for each transaction
• The balance is displayed for every transaction for the full period of time transactions are available
• The balance is not displayed if a filter has been applied

Although the story's title and acceptance criteria should detail everything the software team needs to know, add any extra information that may be helpful.

Extra information may include:

• User Permissions - Define the role elements the user needs to be assigned in order to access the functionalities in a story.
• Impact in other functional areas
• Dependencies on other user stories, etc.

Attachments can provide more information to help the scrum team understand a user story.

For instance, a user story created from a bug report may require a screenshot of the issue attached in order to speed up the software debugging process.

If UX has designed prototypes for a user story, they can also be attached with the user story.

Large user stories make it difficult for the scrum team to. complete the story within a sprint, and they often make impediments less visible. Thus, it is important to split user stories into smaller ones.

Here are some strategies we can use to effectively split large user stories:

1. Split by steps of a workflow

The user performs a task according to a well-established workflow.  A large user story can be split according to these steps in order to be developed incrementally. Each step has its own user story.

2. Split by scenarios

By splitting a user story by scenario, we can create a user story for the main success scenario and other user stories for any errors or alternative paths.

3. Split by operations

Splitting a user story by operations is often the most obvious way to deconstruct. A CRUD (Create, Retrieve, Update, Delete) feature is a good example. Separating the CRUD or group two operations in a user story may be appropriate...to create an account, view it, edit it, and delete it.

4. Split by user roles

Administrators interact with a system differently from normal users. By defining the different roles in a system, we can split features and stories to address the unique needs of each role.

5. Cross-cutting concerns

Separate out certain properties that all features need to incorporate, which can then be addressed as separate user stories. These include items such as validation, security, and exceptions.

6. Non-functional requirements

Address overarching items, like performance and capacity, as separate user stories. For example, if an app needs to handle 500,000 users, that doesn't need to be incorporated into the first user story of each feature. Get the feature working first, then address the capacity issue with a new story.

Review the story based on the INVEST checklist to evaluate if a user story qualifies as a good story.

The INVEST checklist comes from INVEST in Good Stories by Bill Wake. It's an acronym with six important quality characteristics for user stories:

A good user story is:

I - Independent

N - Negotiable

V - Valuable

E - Estimable

S - Small

T - Testable

Theoretically, all user stories should be independent, but we may never be able to fully achieve that. When dependency happens, the most important thing is to communicate the dependency so that both the project manager and the BA are aware of it. This will force the project manager and BA to either redefine user stories so that the dependency is removed or to redefine business priority accordingly so that the principal user story is implemented first.

Bad User Story

"As a hero I want to see shifts in a list and then apply for a shift."

This user story is not good because:

1. It doesn't provide enough requirement details
2. The story may be too big to be completed in one sprint
3. The story doesn't have Acceptance Criteria, so the scrum team won't know what kind of functionality are needed to meet the user's needs.

Good User Stories

After further grooming of the above bad user story example, it may be rewritten into three user stories.

Story 1

"As a Hero I want to see a list of shifts from different communities to find those I am interested in."

Acceptance Criteria:

1. Verify that Hero can see shift type, shift start time and end time, community that posted the shift, posted time, and hourly rate in the list.
2. Verify that logo of the community is displayed in the shift list.
3. Verify that shifts are ordered by start time, with the earliest displayed on top.
4. Verify that the posted time of a shift is displayed based on Hero's local time, but the start date and end date of a shift is based on a community's local time.
5. Verify that when Hero clicks a shift, Hero is redirected to Shift Details page.

Story 2

"As a Hero I want to see details of a shift I am interested in so that I can decide if I want to apply for it."

Acceptance Criteria:

1. Verify that Hero will see shift type, shift start time and end time, community that posted the shift, posted time, hourly rate, estimated total payment, address and phone number of the community that posted the shift.
2. Verify that community name is displayed as a link and when Hero clicks on it, community details page will be displayed with community logo, welcome message, and parking instructions.
3. Verify that an Apply Now button is displayed at the bottom of Shift Details page.
4. Verify that Back button is displayed on Shift Details page. By clicking the Back button, user will be directed to Shift List page.

Story 3

"As a Hero I can click the Apply Now button to apply for a shift in the Shift Details page."

Acceptance Criteria:

1. Verify that after Apply Now button is clicked, the shift that the Hero has selected is added to their Active Shift list.
2. Verify that if Hero already has a shift that has overlapping time with the selected shift, Hero will see an alert message.
3. Verify that the Active Shift list includes shift type, shift start time and end time, community that posted the shift hourly rate, and status of Applied.

After a user story is completed and reviewed, it needs to be moved into the product backlog and ready to be prioritized.

Prioritize the Story in Backlog

The story needs to be assigned a priority. Priority will decide which of these stories are of the highest value and critical to success, and build those items first.

A user story can be prioritized as one of the following:

• Score 5: Business Critical
• Score 4: High Priority
• Score 3: Important
• Score 2: Low Priority
• Score 1: Nice To Have
• Score 0: No Priority

After the prioritization process, the user story must also be sized.

User Story Points (USP)

Sizing involves User Story Points (USPs), which are an abstract measure of effort required to implement a user story.

At GST, USPs use the Fibonacci sequence as a scale for sizing:

1, 2, 3, 5, 8, 13, 21, 34, 55 ...

The raw value of a user story is not as important as the relative value of a user story.

• This means that a story assigned 2 USPs should be worth twice as much as a story assigned 1 USP.

Sizing is important, as it:

1. Provides an overview of the scope of work
2. Determines the size of work using several different perspectives
3. Clarifies false assumptions

Multiple factors are considered in the sizing process:

1. The amount of work to do
2. The complexity of work to do
3. Risk in doing the work
4. Time/Duration

A general outline of the sizing process is:

1. List all stories to be sized
2. Order them from smallest to largest
   1. If you can establish a baseline story which everyone can agree upon, other user stories can be sized through comparison with the baseline. 
   2. Compare the first and second user story to see which is bigger, and place the bigger one above. Then, take the next story, and determine its position relative to your initial two. Continue this process for the rest.

NOTE: When starting from the bottom, it's a good practice to assign the smallest user story you initially find 2 USPs. This is so that if you find an even smaller user story later on, you can just assign it 1 USP.

User Story Points Practical Estimation Standard

GST has the following rules for sizing user stories:

1. The smallest possible feature a user can experience (outside a single label change) is 1
2. Use the Fibonacci sequence for user story size estimate: 1, 2, 3, 5, 8, 13, 21, 34, 55 ...
3. Estimate user story size with the team: Let’s say you have 3 people to do product backlog grooming on a particular user story. One estimates it’s worth 2, another estimate it’s worth 8, another estimates it's worth 13. Use the mean (middle) number 8 as the user story size.
4. Single label change, single spelling check change is 0 (not 1), a group of label change, spelling change can be regarded as 1.

Stories will be moved to sprints based on their priorities. User stories will go through the following stages in a sprint:

1. Proposing Sprint

While BA is working on defining the requirements with the parties involved, the client will review and determine the priority of the user stories which will be the basis for sprint allocation.

2. Approving Requirements

After a sprint has been proposed and the BA has worked on the requirements of the user stories included, BA will send the requirements to the client for approval. The client will review and provide feedback or approval for requirements.

3. Creating UX Screens

After user stories have been created and proposed for a sprint, the UX designer will work on the screens for the user stories that require prototypes and send them to the client for approval and feedback.

4. Approving UX Screens

The client will review and provide feedback or approval for UX screens.

5. Estimating

After both the UX screens and requirements have been approved, user stories can be estimated and worked on by the Dev team.

The Dev team will review user stories proposed for the sprint and deliver an estimation of time and effort.

6. Finalizing Sprint Proposal

When the Dev team presents the effort estimation, the client will review it and decide which user stories to work on in the sprint.

7. Development

The Dev team will develop and release on QA environment.

8. QA Testing

QA will test user stories against test cases and request client UAT after completing testing.

9. UAT

The client will review and work on UAT, and provide comments on improvements and bugs.

10. Approving Sprint

After all user stories have been approved on UAT, the sprint can be finalized.