Click to edit Master title style

CSE334
L3
Agile Requirements
Techniques:
Delivering Value Quickly
Click
Agendato edit Master title style
• Understand why Stories are used for requirements in Agile.
• Appreciate the discipline needed to effectively refine Stories based on
their priority.
• Understand how to decompose Stories into finer grain work items.
• Learn how to slice stories vertically through the software architectural
layers to provide increments of value.
• Learn how to capture nonfunctional requirements via Stories.
• Learn what the different types of Stories there are in order to capture
different user needs.
• Get exposed to the concept of a Minimal Viable Product and why it
accelerates value delivery and learning.
Click to edit Master title style
Requirements

50% • What percentage of overall project time is spent gathering,

elaborating, and communicating product requirements?

35% • What percentage of requirements, as originally defined, change

during the course of the project?

45% • What percentage of features, as ultimately delivered, are rarely

or never used by the product’s end-users?
Click to edit
Delivering Master
Value title style
Sooner

12 month cycle
to deliver value
Click
The 5to edit Master
Levels title style
of Planning

- torak.com
Click
Whattois edit Master
a User Story title style

A brief, simple requirement statement from a user’s

perspective.

- Davisbase
Click Parts
to edit
ofMaster title style
a User Story

1 Who As a <user role>,

2 What I want to <goal>,
3 Why So that <desired benefit>.

Acceptance
4
Criteria

- Davisbase
Click to edit
Information Master
Associated title
with style
a Story
Title: a
conversation Title: Traveller wants to book a trip so that they can go to their destination
starter Story points : 3
Assigned to : Tom
Acceptance tests:
Body 1. User can edit an airline booking
2. User can edit a car rental booking
3. User can edit a hotel booking
4. User can start editing from a screen that shows a booking
Other information:
• Attachments
• Screenshots
• UML
• Discussion
• Non-goals
• Additional details
Click to edit
Benefits Master
of User title style
Stories

• User Stories emphasize verbal rather than written communication.

• User Stories are comprehensible by both customers and developers,
encouraging greater levels of customer participation.
• User Stories are the right size for planning.
• User Stories are well suited for iterative development.
• User Stories force requirements validation by stating both WHO will
use a feature & WHY it is desired.
Click
Whatto edit
Are Master
User title
Stories style
Used For?
• User stories are the basis for all work
• All development work should be based on user stories, no
matter where those developers physically sit
• All test plans should be based around user stories, no matter
who is doing the testing
• User stories may be insufficient for documenting the current
architecture or functioning of the system
– In this case, documentation for this specific purpose may be used
– This documentation should not be used as the basis for development
and testing, only as reference material or for auditing purposes
Click to editCriteria
Acceptance Master title style

• Acceptance Criteria as “Conditions

that a software product must
satisfy to be accepted by a user,
customer or other stakeholder.”
• Acceptance Criteria are a set of
statements, each with a clear
pass/fail result, that specify both
functional (e.g., minimal
marketable functionality) and non-
functional (e.g., minimal quality)
requirements
- manifesto.uk
- seguetech.com
Click
The 3to edit
C’s of Master title style
a User Story

1. The Card - A 3x5 index card forces brevity. Only capture the topic
of the item, a high level description of the desired system behavior,
and why it is important.
2. The Conversation - A User Story it not enough. Consider it a
placeholder for conversation. Detailed requirements are only
discovered once the story has been targeted for a sprint.
3. The Confirmation - On the back of the card capture Acceptance
Criteria. They outline specifications from the Product Owner and will
allow the team build functionality for acceptance.
Click
Where toUser
edit Stories
MasterFit
title
In style

Must have User Stories

written, estimated &
prioritized prior to
Release Planning.

- Davisbase
Click to edit
Product Master title style
Backlog

• A prioritized list of all user stories that may be delivered

• New items can be added at any time to the Product Backlog
• Items are defined and prioritized by Product Owner with input from
others
• Team members estimate items in Product Backlog relative to each
other using predetermined scale (story points)
Click to edit Master title style
I.N.V.E.S.T.ing

• Independent
• Negotiable
• Valuable
• Estimable
• Small

- Agile Planet
• Testable
Click
Who to editstories?
writes Master title style

Everyone.
• Driven from Product Owner
• Assisted by the Team
• Requires Collaboration

Together as a team you can be successful.

Click to editthe
Prioritizing Master title style
Backlog

• Financial Criteria
• Decision Matrix
• MoSCoW
• KANO
Click to edit Master title style
User Roles
• Why are User Roles important?
• Unique perspectives change requirements and acceptance criteria
• Who are your target customers?
– What do they use the software for?
– How do they use the software?
– What are their priorities?
Click
Story to edit Master title style
Mapping

- winnipegagilist.com
Click to edit
Lifecycle of aMaster
Story title style

High-level
Story is Prioritized Story is planned for Story is targeted
Story is Written acceptance criteria Story is Estimated
in backlog a Release for a Sprint
defined

By PO w/ Team By Team w/ PO By Team w/ PO

By anyone on team By PO, BAs By Team
input input input

Story’s tasks are Story’s Tasks are Story is Groomed

Story is Accepted Story is Demo’d Story is Reviewed
completed defined

By Product Owner By Team By team By team By Team By Team & PO

Sprint
- Davisbase
Click to edit
Defining Master title style
Ready

- romanpichler.com
Click toIngredients
Typical edit Masterintitle style of Ready
Definition

• Meets the INVEST criteria

• Has acceptance criteria
• Very little to no research, or all research
– If a lot of research is required for a story, create a research-only story and time-box it
• The story is estimated
• UAT is well understood
– Preferably fully stated as part of story… or…
– QA person proxy for UAT tester
• Whole team feels comfortable that they know what it takes to get story to “done”
• The whole team has contributed to the grooming/estimation of the story
Click to edit
Backlog Master title style
Refinement

Product backlog refinement—sometimes called

product backlog grooming in reference to keeping the
backlog clean and orderly—is a meeting that is held
near the end of one sprint to ensure the backlog is
ready for the next sprint.

- mountaingoatsoftware.com
Click to edit
Refining Master title style
the Backlog

- leanpub.com
Click to edit Master
Decomposing Storiestitle style

- leanpub.com
 Click
Levelstoofedit Master
Agile title style
Requirements

Vision

Capability Capability

A story too large to

finish in one iteration Feature Feature

Epic Epic

Story Story Story

Click
Slice ittoUp
edit Master title style

Take slice of the whole rather

than individual layers.
“An authenticated member can post a
recommendation for a book”

- ✖ An authenticated member can fill out a recommendation form

- ✖ Information on a recommendation form is written to the database
- ✔ A member can post a written review about the book
- ✔ A member can post a rating about the book
- ✔ A member can post references to similar books
- Mike Cohn
Click
Opentovs.edit Master
Closed title style
Stories

• Open stories often have no end in sight

– “As a Publisher, I want to manage the ads I have placed”
• Closed stories show an achievable, meaningful accomplishment
– “As a Publisher, I want to change the expiration date of an ad”
– “As a Publisher, I want to delete an ad that is no longer relevant”
– “As a Publisher, I want to measure how many times an ad has
been clicked through”

- Mike Cohn
Click to editApproaches
Additional Master title
tostyle
Split Stories
• Splitting by Acceptance Criteria
• Splitting by User
• Splitting by Items in a List
• Splitting by Create/Read/Update/Delete or the Word
“Manage”
• Splitting by Keyword
• Splitting with Lists
• Splitting by Test Scenario
Click to edit
Size the StoryMaster
to the title style
Horizon
• Focus attention on most critical areas first
• Write stories at levels based on the implementation horizon

If stories are further out, they can be Open/Goal Stories

– “…Guest Member I want to register for an account…”
– “…Authenticated Member I want to post a recommendation…”
– “…Pioneer Member I want to submit feature suggestions…”
– “…Critic I want to post reviews of a book…”

- Mike Cohn
Click to edit
Size the StoryMaster
to the title style
Horizon

Once a story is close to being started, break it down.

“As an Authenticated Member, I want to log into the system so that my
information can only be accessed by me.”

...I want to log in with my username and password...

...I want to change my password...
...I want the system to warn me if my password is easy to guess...
...I want to be able to request a new password so that I am not locked out if I
forget it
...I want to be notified if there have been three consecutive failed attempts to
access my account...

- Mike Cohn
Click to edit
Non-User Master title style
Stories

• Technology foundation stories

– At times these can be stated in
customer terms As a developer, I want to upgrade to
• Dependencies from external teams the latest version of the database
software so that we have a supported
• Creative elements
product
• Spikes
• Other types of stories... defects, Spike: As a developer, I need to
maintenance, training, etc. investigate a semantic search
algorithm to facilitate natural
language searching of the person’s
financial record.
Click to edit
Non-User Master
Stories: title style
Constraints

• Constraints often do not

represent user As a patient, I want the system to
functionality. function like the other systems in the
suite so that it is familiar and easy to
• Should be documented use.
and remain visible for
team, but does not go into
the product backlog. As a stakeholder, I want page load
times to conform to current
• Should be stated in standards so that patients will be able
measurable terms and be to use the system on a dial-up
testable connection.
Click to editvs.Master
Functional title style
Non-Functional
• Functional - Captured through User Stories

As a <user role>,
I want to <desired FUNCTION>,
so that <desired benefit>.

Acceptance Criteria could also elaborate on functions.

• Non-Functional - Captured in Several Ways
– Acceptance Criteria
– Definition of Done
– Constraints of the Product
Click to editfor
Guidelines Master title style
Good Stories
1. Start with Goal Stories
2. Slice it Up
3. Open vs. Closed Stories
4. Size the Story to the Horizon

- Mike Cohn
Click to edit
Outputs fromMaster title style
Story Types

• User Stories Demonstrable working software for acceptance

by the Product Owner.

• Foundational Working software, infrastructure, or systems that

enable User Stories to be completed.

• Spikes Information or a decision.

Click
Whattotoedit
WatchMaster title style
Out For
Mike Cohn’s ‘Catalog of Story Smells’
• Stories that are too small
• Stories too big....too many being split later
• Interdependent stories
• Goldplating
• Too much detail
• Interface detail too soon
• Thinking too far ahead
• Lack of customer participation,
writing and prioritizing
Click to edit Master title style
References