MGMT 4066 – AGILE

PROJECT MANAGEMENT

CLASS 4 – CAPTURING AND

PRIORITIZING USER STORIES

Costin Laurentiu

[email protected]
TODAY’S AGENDA:
• Capturing Requirements
• Elements of a Good User Story
• Prioritizing Requirements
• Customer Satisfaction and the Kano Model
• Lean’s Seven Forms of Waste

2
TODAY’S LESSON EXPECTATIONS
• Create User stories
• Define and prioritize requirements
• Describe the components of a user story and how to follow the INVEST and
3C approach to ensure user stories are created with quality.
• Describe the MoSCoW approach to user story prioritization.
• Describe how business value can be identified using the Kano model.
• Identify Lean’s seven forms of waste.

3
USER STORIES
• User Story represents a small, concise statement of functionality or quality
needed to deliver value to a specific stakeholder.

Capturing the Need of

a Specific Stakeholder

Basis for Identifying

Needs and Price
Estimation, Planning
A Sentence or Two that
Describes who has the
Need Addressed by the
Story

• Statement of Value: "As a <who>, I need to <what>, so that <why>."

"Given...When...Then" is another common format.

4
USER STORIES
EXAMPLES

5
USE CASES AND SCENARIOS
• Use Cases and Scenarios describe how a person or system interacts with the solution
being modelled to achieve a goal.

Describe the interactions between the…..

Primary Actor Solution

Secondary Actor
• Use cases are usually triggered by the primary actor, but in some (Needed to achieve the
methods may also be triggered by another system or by an Primary Actor’s Goal)
external event or timer.
• Describe the possible outcomes of an attempt to accomplish a
particular goal that the solution will support.

6
USE CASES AND SCENARIOS

7
USE CASES AND USER STORIES

https://www.youtube.com/watch?v=a3v4-KmDbQA 8
USE CASES AND SCENARIOS EXAMPLE

https://www.youtube.com/watch?v=oesoKbn0yeA 9
PRIORITIZE REQUIREMENTS
• Purpose: Rank requirements in the order of relative importance.
• The act of ranking requirements to determine their relative importance to
stakeholders.
• Prioritization is an ongoing process, with priorities changing as the context changes.
• Prioritization is a critical exercise that seeks to ensure the maximum value is
achieved.

10
BASIS FOR PRIORITIZING REQUIREMENTS
• The basis on which requirements are prioritized is agreed upon by relevant stakeholders
(and determined by product owner). Typical factors that influence prioritization include:
• Benefit
• Penalty
• Cost
• Risk
• Dependencies
• Time Sensitivity
• Stability
• Regulatory Compliance

11
PRIORITIZING REQUIREMENTS
• Challenges of Prioritization
• Prioritization is an assessment of relative value. Each stakeholder may value
something different. Stakeholders may also have difficulty characterizing any
requirement as a lower priority, and this may impact the ability to make necessary
trade-offs.
• Continual Prioritization
• Priorities may shift as the context evolves and as more information becomes
available. As the requirements are further refined, prioritization is done at a more
granular level and will incorporate additional bases for prioritization as they become
appropriate. The basis for prioritization may be different at various stages of the
change based on factors such as benefits or cost.

12
PRIORITIZING REQUIREMENTS AND USER STORIES
• Value streams help identify requirements and user stories. Once identified,
requirements or stories should be prioritized.
• The MoSCoW prioritization model, developed helps to organize and structure
requirement and user story priority.
• Must-have requirements—These requirements are mandatory. The project cannot launch unless they
are fulfilled.
• Should-have requirements—These requirements are high priority. Their absence may not prevent a
project from launching but may prevent an organization from realizing the full benefit of the project.
• Could-have requirements—These requirements aren’t as high in priority but could represent additional
value.
• Won’t-have requirements—These requirements will not be included in a release or project. They can be
included in later phases, but for the purpose of the project, are removed from planning and further
discussion.

13
MOSCOW PRIORITIZATION TECHNIQUE

14
BALANCING REQUIREMENT PRIORITY

For the purposes of planning, requirements should be

distributed across categories.
• Must-have requirements should not exceed 60 percent of the
overall distribution. A greater percentage can add additional
risk to the project.
• Could-have requirements should not exceed 20 percent of the
overall distribution. More than this would indicate that the
project may not be achieving business value, and numerous
superficial features or requirements are being implemented.
• Should-have requirements should represent the difference
between the must-have and could-have requirements.

15
USER STORY CARDS
• User stories typically follow a simple template: As a <type of stakeholder>, I
want <some goal> so that <some reason>.
• Additional elements of a user story include the following:
• Size/points—These are used to help estimate the user story for planning purposes.
• Business value—This captures the value the user story contributes to the organization,
project mission, or customer and can help prioritize the story.
• Verification criteria—These capture how the user story can be verified as complete
and will be covered later in this chapter.

16
USER STORY CARDS

17
USER STORY CARDS

18
INVEST IN CREATING GOOD USER STORIES
User stories should follow the INVEST guideline. INVEST is an acronym that
outlines the attributes that define high-quality user stories.
• Independent—The story is discrete and can be fulfilled independently of other user
stories.
• Negotiable—The story is open to negotiation of how it can be best fulfilled.
• Valuable—The story contributes to achieving value.
• can be Estimated—The story can be estimated by the development team.
• Small—The story is discrete and incremental in achieving value.
• Testable—The story can be verified and validated.

19
THE 3 CS OF USER STORY CREATION
The INVEST approach supports the 3 Cs of user story creation.
• Concise/card—The user story is short enough to fit on a 4 × 6 card.
• Conversation—The user story is supported by a conversation or is a starting point for a
conversation between business and project teams.
• Confirmation—The user story should include acceptance criteria to help the development
team better understand the requirement and expectations of the story.

20
DECOMPOSITION OF USER STORIES
• Agile user stories need to be specific enough to estimate. Therefore, stating that a user
would like to manage customers using a single interface may not be broken into sufficient
detail for the development team to estimate.
• When considering how to further decompose a user story, the CRUD approach can be
used. CRUD is an acronym that represents standard functions for most software.
• Create—The action of adding a new entry into a system
• Read—The action of being able to retrieve and review a system record
• Update—The action of modifying an existing system record
• Delete—The action of removing, hiding, or disabling a system record

21
BUILDING QUALITY IN
• Test-driven development requires the verification criteria to be created before the code;
this approach can help developers ensure they build a feature that will pass verification.
• TDD supports the Lean concept of jidoka. Jidoka is a Japanese term. The goal of jidoka is
to support activities that “build in” quality. Rather than identifying defects after a product
has been completed, the goal of jidoka is to minimize defects from occurring in the first
place by fixing the defect-causing behaviour at its source.

22
ENSURING USER STORY VALUE
• Business value is another key concept to both a good user story and Lean.
• Lean defines a value-added activity as one that meets these criteria:
• It transforms the product or service.
• Customers are willing to “pay” for it.
• It must be done correctly the first time.

23
VISUALIZING VALUE AND CUSTOMER SATISFACTION

• To help visualize value, user stories can be placed in a Kano

model. The Kano model is a product development and
customer satisfaction approach. The Kano model breaks
products into categories that help identify activities that drive
customer satisfaction and business value.
• Must-be or needs qualities—This category captures the
elements that customers often take for granted and that, if
not fulfilled, create customer dissatisfaction.
• One-dimensional or wants qualities—This category is linear.
Customers are satisfied if their wants are fulfilled and are
dissatisfied if their wants are left unfulfilled.
• Attractive or delighter qualities—This category provides
satisfaction when fulfilled but does not generate
dissatisfaction if left unfulfilled.

24
KANO MODEL

https://www.youtube.com/watch?v=U4eERNtgQo8 25
LEAN’S SEVEN FORMS OF WASTE
Another method of identifying value is the elimination of waste. Value stream mapping
identifies obstacles that are impeding a process from achieving optimal flow. Business value
can be assigned to a story by identifying the type of obstacle(s) a story removes. Lean
identifies seven forms of waste:
1. Transportation waste—Materials, information, or resources are unnecessarily moved to fulfill a process.
2. Waiting waste—Resources are idle while they wait for a dependent process or activity to be completed.
3. Overproduction waste—Resources are producing more than necessary to achieve customer needs.
4. Defect waste—The process results in an unacceptable outcome.
5. Inventory waste—Additional resources or work in progress items do not directly contribute to or impede
a process’s ability to achieve customer value.
6. Movement waste—Materials, information, or resources are excessively moved to complete a specific
process activity.
7. Extra processing waste—Work is performed that is not required to satisfy the customer need.

26
PRIORITIZING USER STORIES AND OTHER BUSINESS
PROCESSES
• Consider the application of value stream mapping and user story
prioritization through MoSCoW and Kano approaches.
• What other business processes could be supported by such activities?

27
IN-CLASS EXERCISE

• Consider your approach to your studies. Create a value stream/ process map.
Identify where there may be waste.

28
WHAT WE LEARNED TODAY

• How to create user stories

• How to prioritize user stories using the MoSCoW model
• How to create high-quality user stories using INVEST and 3Cs
• How the Kano model can be used to identify business value
• Lean’s seven forms of waste

29
NEXT LESSON

• Capturing and Prioritizing User Stories (Cont.)

• Introduction to Assignment 2

30
NEXT WEEK – WORKING SESSION +
ASSIGNMENT 2 INTRODUCTION

Costin Laurentiu

[email protected]