Building blocks for lean agile requirements (c) technology expresso v12 @Jacqueline007

Building Blocks for
Lean Requirements
v3.0
1
Presented by Jacqueline Sanders-Blackman

3
Lean Requirements
● Lean is the Art of Work Left Undone
● Lean is getting the results you want with the least amount
of work
● Lean is a systematic approach to Avoiding Waste
● Lean is the way you approach a body of work
● Lean is a philosophy, perspective and how you use your
existing tools

Building Blocks of Lean Requirements
● Intro to Lean Requirements Building Blocks
● 3C’s - Card, Conversation, Conﬁrmation
● An introduction to INVEST
● 4 R’s of the User Story Cycle
● Visualizing Requirements - Keeping It Lean
4
Technology Expresso © 2021

Building Blocks to Lean Requirements
Invest in good stories and create SMART (Specific, Measurable, Achievable,
Realistic and Timeboxed) tasks. Good User stories are easy as 3 Cs, 4 Rs,
INVEST!
❑ Card
❑ Conversation
❑ Confirmation
❑ Raw
❑ Rough
❑ Refine
❑ Ready
Independent - Negotiable - Valuable - Estimable - Small - Testable
5
❑ Independent
❑ Negotiable
❑ Valuable
❑ Estimable
❑ Small
❑ Testable

An Important Agile Requirements Tool
6
Miro for Requirements as a Virtual White Board

Just In Time Requirements
❏ Backlog should contain 2 - 3 Sprints of Ready
❏ Guidelines to help relatively size the item
❏ Small pieces of work to avoid hidden complexity
❏ Address Spikes as needed
❏ Know that some stories will be descoped
❏ Apply MVP at the Feature, the
Story, the Acceptance Criteria Level
❏ The leaner the requirements the
More frequent the conversations and demos
❏ Stability helps build a common
understanding
❏ Leave visual breadcrumbs for newcomers
❏ Not every new story is a priority
7

1. Card
2. Conversation
3. Conﬁrmation
9

User Story Life Cycle
Need
idea
problem
goal goal
Business
change
Customer
impact
Software
Change
ideas
“epics”
“stories”
Implementation
detail
sUb-Tasks
Tasks
“Enablers”
10

User Stories - Card
To create a concise but useful user story,
formats for user stories are commonly
used.
Most common format:
As a < user >
I want <goal>
So that <value realized>
or
As a <who>
I want <what>
So that <why>
User stories are written on cards to limit the length of a user story, which
encourages a concise description of the critical elements of the user story.
Example:
11

User Stories – Conversation
User stories are reminders for further conversation - What not How.
US 12
As a customer I want to be able to look at the history of
my campaigns and to be able to reuse campaigns without
having to manually recreate them.
Additional Notes:
- Include the campaign start , end date, and
demographics
12

User Stories – Confirmation
Examples of acceptance criteria:
● Date field in mm/dd/yyyy format
● Time field in hh:mm format
● Unavailable Status: Vacation,
Personal, Time Off, Transit
● Unavailable Status: Other, with
option to enter free-form text
● Ability to add or update an entry
that is not in the past
Acceptance criteria are developed to verify that the
user story was delivered correctly; they often provide
functional details.
13

Creating Acceptance Criteria
14

Investing in Good User Stories
● Independent
● Negotiable
● Valuable
● Estimable
● Small
● Testable
16

I - Independent
User stories can be delivered in any order, and the delivery of
one user story is not dependent on the delivery of others.
● Independent stories are easiest to work on.
● They should not overlap.
● They should be scheduled and implemented in any order.
● Having a lot of stories that have dependencies makes it
hard to prioritize, causes planning problems, makes
estimating harder.
17

N – Negotiable, not Negotiated
User stories are reminders for a conversation, not a contract.
They should allow for some ﬂexibility as to the details of
implementation.
● A story is not an explicit contract.
● A good story captures the essence, not the details (design
is co-created during the sprint).
● Over time, the card acquires notes, tests ideas, etc.
● We don’t need the ﬁnal details to prioritize or schedule
stories.
18

V - Valuable
A user story, when delivered, helps a stakeholder accomplish
something or they provide observable behavior that the team
and stakeholders can learn from.
● It needs to be valuable to the customer.
● Make each user story/slice vertical not horizontal.
● Make every user story/slice valuable.
19

Paradigm Flip
20
FIXED
Adaptable
Plan
driven
Vision
and value
driven
Features Cost Time
Timeline Features
Cost

Finding the MVP
Customer
wants
this
Your MinimumViable
Product (MVP)
What the
company can
aﬀord
You think
the market
needs this
What the
company
wants to
spend or
what the
customer
will pay
21

Minimum Requirements = MVP
22

E - Estimable
The team needs to be able to estimate the size of the story fairly
easily. Story Writing and Estimating is a Team Effort.
Tips on agile estimating:
● Estimating is a team sport
● Includes the product owner
● Story points not hours
● Up-level your estimates
● Learn from past estimates
● When you reﬁne a story, revisit the size
23

Progressive Estimating Elaboration
T-shirt Sizing
(XS, S, M, L,
XL, ?)
Fibonacci /
Modified
Fibonacci
Story Points
(0, ½, 1, 2, 3, 5,
8, 13, 20, 40,
100, ? or Spike,
infinity)
Ideal Days
Note: Not the
same as
actual
duration/days
Task(Optional)
Hours
Story Status
Placeholder………………………………………..……….Committed to a Sprint
24

Relative Sizing Retros
● As a group, have team members position
the stories on a board (physical or virtual)
based on relative size.
● Label the columns with relative sizes.
● Estimate typical story or samples of stories
for each category and make a ledger.
● Identify some of the characteristics that
diﬀerentiate the categories.
● Change in team doesn’t change the LOE.
Team changes are compensated via the
Velocity.
1 2 3 5 8
Story Story
Story
Story
Enabler
Story
Story
Story
Tech
Debt
Story
Story
Story
Story
25

S - Small/Sized Appropriately
The user story needs to be small enough to be completed in
an iteration.
As a Business Owner, I want
to be able to see the new
transaction on my account as
soon as they happen so that I
can react to sudden surges in
business activity.
As a customer, I want to have
the option to have status
changes for my purchases
sent to me so that I have a
clear idea of when my
products are going to arrive.
26

Vertical Slices
27

Various Ways to Split and Slice Stories
Subset of steps within the
process/workflow
Can you split the story based on the workflow, and focus on one or two pieces that
need to be improved the most?
Split the process steps Can you slice the workflow and do part now and the other part later?
Delay throughput requirements Could you split the story with the goal of making it for a low volume of transactions and
improve it later to work for a high volume of transactions?
Defer Security, Performance,
Efficiency, Dependability,
Usability, Operational,
Maintainability, Compliance
Does the story get its complexity from non-functional requirements?
Operations (CRUD) Does the story include multiple operations?
Business Rules Variations Can you split a subset of the rules and do some later? Does the story have mandatory
versus optional rules?
Variations in Data Can you split the story by mandatory data versus optional data? Does the story do
different things for different data?
Complex Interface Is there a simple version of the interface? Can you do different interfaces by data
sources?
Major Effort Could you do the most difficult parts first and defer the rest of the story?
Simple/Complex Could you find the simple core of the story first and enhance it later?
Testing Could you split the story based on how the testers will approach their testing?
28

T - Testable
User stories must be written so that it is clear when they have
been delivered and they meet the customer’s expectations.
29

Generate Examples
Teams in an agile environment use examples to provide more detail about
user stories and to confirm they were delivered properly.
30

Four “R”s
Raw
❑ A descriptive title
❑ Relationships
Rough
❑ Identify the Why, Who and What
❑ Add bullet points/initial acceptance criteria
❑ Have conversations with SMEs
❑ Attach samples, pictures, outline, flow
❑ Identify data source
Refine
❑ Include in grooming session and activities
❑ Update story, finalize acceptance criteria
❑ Identify actors, data, business rules and processes
❑ Identify potential sprint
❑ Story decomposed
❑ Points, priority
❑ Initial thumbs up
Ready
❑ Task breakdown (as needed)
❑ Hours
❑ Order of tasks
❑ Dependencies/shared service engaged/committed
❑ Final thumbs up
Discuss whether all of these items are required for all stories. Are there any exceptions?
32

Raw
Allow Customer to save
Repeat Buyer
Information
Allow Store Owner to
Display Products
Allow Store Owner to
Accept Orders from
Customers
Allow Customers to
Create a Store
The initial user story is defined as a placeholder for a future
conversation. The user story initially may just be a descriptive name.
Upon further refinement a user story may be broken into multiple stories.
Some user stories may be eliminated altogether, so there is no need to
create a lot of details until it becomes a priority.
33

Rough
Add 3-4 unformatted bullets. Estimate the size of the story
using T-shirt sizes.
As a Donor, I want to review my
donation history, so that I can report
it on my taxes and get the
appropriate tax cuts
34

Refine - Only If Committed
As a Donor, I want to review my donation
history, so that I can report it on my taxes
and get the appropriate tax cuts
Identify acceptance criteria, examples and core
components, major test criteria and re-evaluate
the size of the story.
35

Ready
As a Donor, I want to review my
donation history, so that I can report
it on my taxes and get the
appropriate tax cuts
Identify potential shared services/dependency/
expertise needed for this user story. Re-evaluate
the size of the story.
36

ESTIMATED
Reﬁning New Stories
Discovery Kanban boards are used for new user story triage.
Rough
Raw Reﬁne Ready
NEW READY TO ESTIMATE READY TO
ROCK
Include:
● Item
● Acceptance Criteria
Include:
● Item
● Size
Include:
● Item
● Size
● Mockup
● Dependencies
● Stakeholder list
● Examples
Defn of
Ready
Item
Item
Item
Item
Item
Item
Item
Item
Item
Item
Item
Item
Item
Item
Item
37

Definition of Ready (DOR)
Here is an example of consideration of items that are ready:
● Story defined and written
● Story traceable to source document (where appropriate)
● Acceptance criteria defined
● Dependencies identified
● Size estimated by delivery team
● User experience included (where appropriate)
● Performance criteria identified (where appropriate)
● Person who will accept the user story is identified
● Team has a good idea about how to demo the user story
38

Keep It Lean & Closing the Gap
39

Miro for Requirements - Visual Bread Crumbs
40
● Process
Flow
● Before
Metrics
● Business
Case
● Value
Proposition
● Story Map
● Wireframe
Mockups
● Feature
Map

Visual Modeling to Build a Shared Understanding
Models are a powerful tool for building and
maintaining a shared understanding of context.
41

Objectives to Features to Stories
Epic
Models
Features
Models
User
Stories
Visual Models can provide a big picture to identify
features and user stories.
Epic
Features
Models
User
Stories
42

Visual Refinement Tools for Gap Analysis
❏ Consider the 5 Perspectives
❏ Use Visual Requirement Models
❏ Create a Virtual Whiteboard (Miro)
❏ Brainstorm Scenarios and Examples
❏ Mindmap the Problem
❏ Identify Use Cases and Misuse Cases
❏ Go Down the Happy Path and the Alternate/Negative Paths
❏ Think about the End to End (SIPOC)
❏ Leverage Existing Historical Data
❏ Socialize your Solution
❏ Know your Stakeholders
❏ Cross-reference the 5 Core Software Components
❏ Don’t forget Non-functional and Enablers
❏ Look for Technical Debt
❏ Trust but Verify
You may ﬁnd missing Features, Epics, Acceptance Criteria, Technical Story and more
Technology Expresso © 2021 44

(Six Sigma) SIPOC
4 Core Components of Software - Data, Process, People, Business Rules + NFRs
45

Examples and Scenarios
Using a mind map, determine how many paths
can you come up with for this user story, then
re-evaluate the size of the story.
● Data
● Process
● People
● Dependencies
● UX Design
● Business Rules
● NFR
46

Non-Functional Requirments
● Performance
● Security
● Availability
● Usability
● Maintainability
● Recovery
● Reliability
● Integrity
● Help Documentation
47

Use Case
● Happy Path
● Alt. Path
● Negative Path
● Misuse Cases
● Edge Cases
● Reuse
● Pre-Conditions
● Post-Conditions
48

Continuous Learning - Recommended Resources
49

Additional
Recommended
Continuous Learning
Modules
52

Advance Team Story Writing Workshops
Acceptance criteria driven product discovery
❏ Create a Story Map
❏ Do High Level Estimates
❏ Identity MVP
❏ EveryoneTakes a Story
(focus on MVP ﬁrst)
❏ Writes the Story
(Feature andTechnical
Stories)
❏ Read the Stories One at
aTime
❏ Everyone Provides
Feedback
❏ Re-estimate Stories
❏ Vote on Status of Story
Participants
Product Manager/Owners
SMEs
Operation/Support Reps
Tech BAs
User Experience Designer
App Developers
Architects
Testers (QA+UAT)
Project Managers
Elevator
Pitch
Business
Goals
Chartering
Personas
Story Mapping
Planning
User Story Authoring
Pragmatic
Personas
User
Goals
Scenarios &
Narratives
Day in Life
of each
Persona
Activity Map
Task Map
Interaction
Design
UI Sketch
Reiterating
Grouping by
Themes
Prioritisation
Acceptance
Criteria
User
Stories
A
c
c
e
p
t
a
n
c
e
C
r
i
t
e
r
i
a
53

Building blocks for lean agile requirements (c) technology expresso v12 @Jacqueline007

Recommandé

Recommandé

Contenu connexe

Tendances

Tendances (20)

Similaire à Building blocks for lean agile requirements (c) technology expresso v12 @Jacqueline007

Similaire à Building blocks for lean agile requirements (c) technology expresso v12 @Jacqueline007 (20)

Plus de Technology Expresso Expresso-Consulting

Plus de Technology Expresso Expresso-Consulting (20)

Dernier

Dernier (20)

Building blocks for lean agile requirements (c) technology expresso v12 @Jacqueline007