Agile - User Stories

Initiatives、Epics、Stories

Every software team has a process they use to complete work. Normalizing that process–i.e., establishing it as a workflow–makes it clearly structured and repeatable, which, in turn, makes it scalable.

From the largest objectives down to the minute details. You’ll want to be able to respond to change, report your progress, and stick to a plan. Epics, stories, themes, and initiatives are precisely the tools.

• Themes are large focus areas that span the organization, like organization goal that drive the creation of epics and initiatives.

• Initiatives are collections of epics that drive toward a common goal, like a product roadmap.

• Epics are large bodies of work that can be broken down into a number of smaller tasks/stories.

• Stories: also called "user stories" are short requirements or requests written from the perspective of an end-user.

What are the steps to write great Agile User Stories?

A common User Stories template has a specific workflow to help deliver:

1. Make up the list of your end-users. Define what their "pain" or "need" is, which you’re trying to solve.

2. Define what actions they may want to take.

3. Find out what value this will bring to users and, eventually, to your product. Also, ask yourself - will any party pay us for this?

4. Discuss acceptance criteria and an optimal implementation strategy.

Step 1: Think of the "Who"

This is the first and, maybe, the most fundamental step. Before writing a User Story you should actually know who the end-users of your product are. And more important - what needs they have, which you are trying to cover.

• It’s all about the user. Not about developers. And even not about a Product Owner. Each Story should be valuable to some group of your end-users.

• Don’t think of users only as external customers. It’s true that your Stories will be mostly about them. But it’s also true that you have to consider internal users such as admins, editors etc.

• Feel some empathy. Give your "user" a name. Think of his mobile habits, what issue your app is going to get resolved for him and how you’re going to make this path easier and faster. Remember some people who you know from real life and who fit this portrait; feel how you relate to this target group.

Step 2: Think of the "What"

Now we have a few groups of end-users. The next step we do is define what functionality each user expects, how he’s going to interact with the app.

These are the main rules to remember when writing an action for a Kanban or Scrum User Story:

• One action per Story. If you want to write something like "as a customer I want to browse items and add them to the cart" you’d better split it into 2 separate Stories.

• Describe an intention, not a feature. For example, instead of "I want to manage my profile" create a few Stories like "I want to be able to register", "I want to upload my profile photo", "I want to link my credit card to my profile" - each Story will have a different value.

• Keep it short. Users don’t care what library you will use to let them browse the list of items so leaves all the tech details aside.

• Avoid describing UI. We’ve defined Stories as negotiable, remember? That's why all good User Story examples don't include any UI details. So don’t try to compose any special way to implement them (we’ll do this later).

Step 3: Think of the "Why"

Finally, the last piece of our User Stories template is dedicated to a value that users get after performing an action.

However, your [so that] section should always correspond with your metrics and KPIs. It should either improve the UX, increase retention rates, shorten users’ journey to the issue solution or whatever. Each Story should contribute something to the general goal of your product.

If you can’t answer what value this feature brings to end-users and your product as well, then you’re doing something wrong.

For instance, there are a few User Stories examples with a well-written value for our ongoing food ordering app project:

• As a customer, I want to get notifications when there are new hot offers so that I never miss the best deals. [how it affects KPIs: users get notified ➡️ they use the app more often ➡️ retention rate grows].

• As a restaurant manager, I want to complement the dish description in the menu with a photo so that it looks more attractive to the customers. [how it affects metrics: users are satisfied that they can see photos ➡️ sales grow ➡️ your revenue also grows].

Step 4: Discuss a Story

Finally, we always discuss User Stories after they’ve been created. Even if it seems like nothing to talk about.

Use the following tips when working on this task:

• Start with Epics. It’s usually easier to move from more complex tasks to more specific ones so try writing Epics and then split them into Stories.

• Listen to feedback. Sometimes you don’t need to guess Stories - ask your real end-users for feedback and use their ideas as a source of inspiration.

• Don’t introduce details too early. It’s better to hold the brainstorming session before each sprint to discuss how to implement planned Stories.

Resources

• The 2020 Scrum Guide

• Scrum Glossary

Requirements

• Functional requirements

  • relates to a result or behavior provided by a function of a system —>

    • Input --> Behavior --> Output

    • Process descriptions

    • Specific functionalities

    • Calculations

—> "What a system should do"

• Non-functional requirements

  • primarily specify how a system should behave and are constraints on system behavior

    • Product properties

    • User experience

    • Performance

    • Quality attributes

—> "How a system should do it"

• How to identify requirements

  • Analysis Techniques:

    • Observation (i.e. shadowing) —> basic attr

    • Questioning (i.e. interviews or surveys) —> performance attr

    • Creativity (change of perspective or brainstorming). —> excitement attr

• Requirements in user perception

  • "The Kano-Model"

    • Basic attributes

    • Performance attributes

    • Excitement attributes

Theory

• Requirements vs User Stories

Requirements	User Stories
system behavior functional & non-functional detailed and complex highly specific —> Waterfall methodology	user experience non-functional short and simple stimulate discussions —> Agile methodology

Example - password reset:

Requirements	User Stories
User must authenticate himself using his email address User must answer a security question User receives an email with an initial password for his account User must change the initial password at first login ...	"As a user, I want to reset my password myself so that I can log in again."

• Role of User Stories in agile methodology

• Why to choose User Stories in agile projects

  • Simple and informal description of how a system or product generates value for the user

  • Basis for communication between product owner and stakeholders

  • Rough documentation of the requirement, refinement takes place in collaborative discussion

  • The completion of the requirements is only achieved through discussion and can be recorded in subtasks

  • Limited scope is ideal for the implementation of increments

  • High transparency and a common understanding

• How to implement User Stories

  • Completely refined User Stories are collected in the Product Backlog as so-called Backlog Items

  • Backlog items represent work packages prioritized by the Product Owner

  • The Product Backlog is continuously reprioritized and extended with new Backlog items

  • In the Sprint Planning, the User Stories are scheduled for implementation in the order in which they were prioritized in the Backlog

  • The implementation of the User Stories takes place in the scope of the respective development sprint

https://medium.com/@yicheng_/initiatives-epics-stories-94d302a88048

How to write User Stories

• Structure

  • Short sentences and short paragraphs wherever possible

  • Avoid unclear nested sentences and ambiguous references

  • Only one requirement per sentence

  • Use consistent terminology

  • Use sentence templates

• Use of sentence templates

As <a type of user>, I want to <perform some task> so that I can <achieve some goal>.

• • Easy to learn and to apply

  • Automatic reduction of linguistic effects

  • Stylistically uniform requirements prevent misunderstandings

  • Can be used for almost all types of systems

  • requirements of high quality through the defined variables

Variables

• <a type of user> —> who is it for? (User)

• <perform some task> —> What should be done? (Objective)

• <achieve some goal> —> why should this be done? (Benefit)

• Three C’s

  • Card

    • Fit on a Note Card

    • Concise format —> Sentence template

    • Only necessary information

    • Invitation to have a conversation

  • Conversation

    • Gain further details

    • Promotes collaboration

    • Common understanding

    • Involve PO, stakeholders and project team

    • Real value of the user story evolves

  • Confirmation

    • Essential requirements

    • Documentation as testable criteria

    • Confirm correct implementation

—> Acceptance Criteria

• Acceptance Criteria

  • Clarify what should be implemented

  • Documentation of the implementation conditions

  • Describe functional requirements, system behavior but also non-functional aspects

  • Must be defined before implementation

  • Are required for a Story to meet the Definition of Ready

  • Help to understand when a story is "done" (Definition of Done)

Example:

"As customer, I want to select a color so that I can see all clothes in this color."

• In a filter section it must be possible to select common colors as filter criteria

• A multiple selection of colors should also be possible

• The filter must be able to be used in combination with other existing filters

• The color must be stored and must be accessible on each piece of clothing

• When the filter is applied, a database query returns only the clothes in the matching color

• The filter can be switched off by clicking on the color again

Online Resources referring to Sentence Templates and the three C’s:

• The Three C’s of User Stories

• Writing User Stories

• Definition of Ready (DoR)

  • Describes when a User Story is ready for implementation

  • Defines which criteria have to be met to drag a story from the product backlog into a sprint

  • Ensures a common understanding of what needs to be implemented

  • Enables realistic estimation and planning

  • Reduces subsequent effort and increases productivity

  • Should be defined and implemented in every agile project

• INVEST criteria for quality control

  • Independent – they can be developed in any sequence and changes to one User Story don’t affect the others.

  • Negotiable – it’s up for the team to decide how to implement them; there is no rigidly fixed workflow.

  • Valuable – each User Story delivers a detached unit of value to end-users.

  • Estimable – it’s quite easy to guess how much time (scope and size) the development of a User Story will take.

  • Small – it should go through the whole cycle (designing, coding, testing) during one sprint.

  • Testable – there should be clear acceptance criteria to check whether a User Story is implemented appropriately.

BENEFITS:

Keep you focused on the business value. It helps to make your app not only well-built from the technical perspective but also useful to the end-users.

Enable creativity. Since it contains a minimal amount of info, your team is free to drive creative ideas to find the best solution to implement a Story.

Your project becomes more manageable. We at Stormotion know that it’s a way easier to work with small and estimable Agile User Stories rather than with big complex tasks.

They inspire the team! Every developer loves this sweet feeling of a small win which motivates him to work even harder.

—> Examples for DoR:

• • • The user story is documented in english language based on the defined template

    • The Business value is clearly articulated by the Product Owner

    • The acceptance criteria must exist, are testable and undersood by the team

    • The user story has been estimated by the team

    • Legal, data security, and data protection related aspects are considered

    • Financing is secured

    • Dependencies are identified and described

• Definition of Done (DoD)

  • Establishes a common understanding of when a user story is considered done

  • Ensures the quality of the feature to be delivered

  • Apples to all Backlog items

  • Not to be confused with acceptance criteria

  • Final check before delivery

—> Examples for DoR:

• Acceptance criteria defined in the User Story are fulfilled

• Deployment to the Test environment was successful

• An acceptance test on the Test environment has been performed and approved

• Documentation was written in English

• Integration tests with interfaces have been conducted

• Implementation meets the Coding Guidelines

When to split User Stories?

• Why do user stories have to be split

  • When a user story is too big for a sprint

  • If too many requirements are described in one User Story

  • If the requirements in a User Story are too complex

  • If parts of the User Story are not needed

• Benefit of splitting User Stories

  • Easier to understand

  • Less refinement required

  • Allow a more accurate estimation

  • Easier to prioritize by the Product Owner

  • Faster implementation and feedback

  • Higher probability to meet the Definition of Done

• How to split User Stories

  • Simple/Complex

  • Operations (CRUD - Create, Read, Update and Delete)

  • Workflow Steps

  • Major Effort

  • Business Rule Variations

  • Data Entry Methods

• What to consider after splitting?

  • Are the split stories comparable in size?

  • Do the split stories meet the INVEST criteria?

  • Is a reprioritization necessary?

  • Is it possible to delete some of the split stories completely?

  • Were the estimates adjusted after the splitting?

Reading Recommendations

Title: User Stories Applied: For Agile Software Development

Author: Mike Cohn

ISBN-13:978-0321205681

Title: User Story Mapping: Discover the Whole Story, Build the Right Product

Author: Jeff Patton

ISBN-13:978-1491904909

Title:Scrum: The Art of Doing Twice the Work in Half the Time

Author: Jeff Sutherland

ISBN-13:978-1847941107