Agile Requirements—From Breadth to Depth

AW6
Agile Requirements
11/16/2016 1:30:00 PM
Agile Requirements—From Breadth to
Depth
Presented by:
Ken Pugh
Net Objectives
Brought to you by:
350 Corporate Way, Suite 400, Orange Park, FL 32073
888--‐268--‐8770 ·∙ 904--‐278--‐0524 - info@techwell.com - http://www.stareast.techwell.com/

Ken Pugh
Net Objectives
A fellow consultant with Net Objectives, Ken Pugh helps companies transform
into lean-agile organizations through training and coaching. His special interests
are in communication (particularly effectively communicating requirements),
delivering business value, and using lean principles to deliver high quality quickly.
Ken trains, mentors, and testifies on technology topics from object-oriented
design to Linux/Unix. He has written several programming books, including the
2006 Jolt Award winner Prefactoring and his latest Lean-Agile Acceptance Test
Driven Development: Better Software Through Collaboration. Ken has helped
clients from London to Boston to Sydney to Beijing to Hyderabad. He enjoys
snowboarding, windsurfing, biking, and hiking the Appalachian Trail. Reach Ken at
ken.pugh@netobjectives.com

Agile Requirements February, 2007
1
info@netobjectives.com
www.netobjectives.com
1 Copyright © 2007 Net Objectives. All Rights Reserved. 7 November 2016
Agile Requirements
From Breadth to Depth
Ken Pugh
Session Sept 2016
Introductions
Name?
What do?
Who for?
Requirements background
Why are you here?
How will you know the session has met your
objectives?
2

2
Ken Pugh
ken.pugh
@netobjectives.com
Photo
Size:
Height: 2.25
Position:
from top left corner
Horizontal 0.75
Vertical 1.
Picture Style: Simple Black
Frame
No code goes in till the test goes on.
A journey of two thousand miles begins with a single step.
Fellow Consultant
OOA&D, Design Patterns, Lean, Scrum, Test-Driven
Development
Over 2/5 century of software development
experience
Author of seven books, including:
– Prefactoring: Extreme Abstraction, Extreme
Separation, Extreme Readability (2006 Jolt Award)
– Interface Oriented Design
– Lean Agile Acceptance Test-Driven Development:
Better Software Through Collaboration
Overall Rules
There are exceptions to every statement, except this
one
Context is everything
4

3
Agile Requirement Objectives
Balance between big picture and details
Layers
Big Picture Project, Theme, Epic
Releasable Unit MBI (Minimum
Business Increment),
MVF
Developable Unit User Story
Requirement
Details
Use Case Scenarios
Acceptance Tests

4
7 7 November 2016
Requirements in
Agile
Requirement Risks (1)
Typical requirement risks and how agile deals with
these:
– Insufficient user involvement
Story based requirements involve users
– Creeping user requirements
Product owner / customer prioritizes requirements
– Ambiguous requirements
Requirement details developed as needed
8

5
Requirement Risks (2)
– Gold plating
Product owner / customer prioritizes requirements
Product owner / customer reviews implementation
– Minimal specification
Requirement details developed as needed
– Overlooked user classes
Most requirement stories have users
– Inaccurate planning
Story based development encourages big to little picture
planning
9
Project Tradeoffs
10
Scope Resources
Time
Quality

6
Software Development Roles (1)
Product stakeholders include:
End users
Management
Marketing / sales
Customer support
Regulators
Gold Owner
11
– Product owner / customer unit
Product manager
Business analysts
Provides:
– Interaction with stakeholders
– Requirements, priorities, and validation
– Accepts/rejects results at iteration end
– Priorities not change in middle of iteration
– Answers team’s questions promptly
Should speak with “one voice”
– Quality assurance – acceptance testing
12

7
– Development unit
Coach / Scrummaster / Project manager
– Removes impediments
– Keeps team in their process
Programmers, etc.
– Building and testing stuff
QA / testers provide:
– Team acceptance testing
13
14 7 November 2016
Big Picture
Project, Theme, Epic

8
Project Charter
Projects start with:
– Charter
Vision – why project should be done
Mission – path to the vision
Scope – boundaries
Objectives – measurable success criteria
– Objectives – These are the tests
SMART
– Specific
– Measurable
– Achievable
– Relevant (to project)
– Time-boxed
15
Charter Example
Sam’s Lawn Mower Repair and Vinyl Rental Store
Vision
– The rental process creates minimum waste and offers more
services to customers.
Mission
– Create a custom software package.
Objectives
– Within two months after project initiation, clerks will spend 50%
less time per transaction on both Album check-outs and returns.
– Within three months after project initiation, customers will be able
to reserve Albums prior to renting them.
Principles
– Customer satisfaction is of primary importance.
– Clerk convenience is secondary.
16

9
Context Diagram
A context diagram shows scope
Process
User
Reports
Commands
Views
Another Context Diagram
Process
User
Another System
Shared Database
Commands
Views
Requests
Responses
Stores
Retrievals

10
Exercise (Optional)
Create a context diagram for your project
20 7 November 2016
Releasable Unit
MBI (Minimum Business
Increment),
MVF (Minimum Viable
Feature)
MMF (Minimum Marketable
Feature)

11
Features and Stories
Features are higher-level requirements
They contain stories – developable requirements
– Can break down a feature into stories (differentiation)
– Can group stories into features (synthesis)
MBI (Minimum Business Increment)
– Feature (or set of features) that when released deliver
business value
– Also known as MVF (Minimum Viable Feature) or MMF
(Minimum Marketable Feature)
Releasable Unit Examples
Sam’s Lawn Mower Repair and Vinyl Rental Shop
– Check out and check in
– Credit card charging to eliminate cash
– Catalog of all Albums so renters can select ones to rent
– Reservation system for Albums
22

12
Exercise (Optional)
What is a minimum business increment (MBI) for your
project?
24 7 November 2016
Developable Unit
User Story

13
Stories
Story
– Interaction between actor and system
– Outcome of value to actor
First need to determine roles (actors)
25
Roles Example
Clerk—Checks out Album and checks them in
Inventory maintainer—Keeps track of overall Album
inventory
Finance manager—Manages all monetary transactions,
such as rental payments and late rental fees
Renter—Pays for Albums with cash or, in the future,
with a credit card
26

14
User Story Template
User story template:
– User or role interested in outcome
– Specific goal or outcome
– Motivation behind achieving goal
– Key conditions or restraints
Template:
– As a <user role>, I want <goal> so that <reason>
Example:
– As the Counter Clerk, I want to check out a Album for a
customer and print the rental contract, so we will know
where the Album is.
27
User Story Examples
As the clerk, I want to check out a Album for a
customer …
As the clerk, I want to check in a Album for a
customer….
As the inventory maintainer, I want to know
where every Album is—in the store or rented …
As the finance manager, I want to know how
many Albums are turned in late and what late
charges apply ..
28

15
Three Facets of a Story
1) Card
– Token representing requirement
Used in planning, discussion
Does not contain details
2.) Communication
– Customer-developer exchange thoughts on details
3.) Confirmation
– Acceptance criteria (details to be shown)
29
Story Map
Time

16
Example Story Map
Rental Workflow
Check-out Album
Activity
Check-in Album
Activity
Check-out Album Check-in Album
Check-out Album that
is already checked out
Check-in Album that
is not checked out
32 7 November 2016
Evaluating User
Stories

17
INVEST Criteria
Independent
Negotiable
Valuable
Estimable (Estimatable)
Small
Testable
Definitions
Acceptance criteria
– General ideas on how to check for “doneness”
Acceptance tests
– Specific tests that either pass or fail
– Implementation independent

18
Story Acceptance Criteria
Check Out Album
– Check out a Album. Check to see that it is recorded as rented.
Check In Album
– Check in a Album. Check to see that it is recorded as returned.
– Check in a Album that is late. Check to see that it is noted as late.
Report Inventory
– Check out a few Albums. See if the report shows them as rented.
– Check in a few Albums. See if the report shows them as in the
store.
Charge Rental
– Check in a Album. See if the rental charge is correct. See if the
credit charge matches the rental charge. See if the charge is made
to the credit card company. Check that the bank account receives
money from the charge.
Exercise (Optional)
What are two roles in your project?
What are two stories for those roles?

19
37 7 November 2016
Details
Use Case
Requirement Precision
Different precision of requirements
– Stories for overall planning
– Stories for current implementation
Implementation requirements
– Need story details
– Need acceptance tests
– One way is to create Use Cases
38

20
Example Story Workflow Details
Checkout a Album (current)
The customer selects a Album from the cases on the shelves.
(The case just has the cover page).
The customer brings the Album case to the clerk.
The clerk gets the actual Album in another case from a shelf
behind the counter.
The customer presents his driver’s license.
The clerk pulls out the rental card from the Album case.
The clerk writes down the customer’s name and the current date
on the rental card.
The customer signs the rental card.
The clerk files the rental card in a box on the counter and stores
the Album case with the cover page on a back shelf.
39
Use Case Template – Part One
Name—Identifier to easily reference it by
Description—Brief note
Actor—Who initiates the use case
Pre-conditions (Given)—
– What must be true before use case is initiated
Post-conditions (Then)
– What is true if use case successfully executes
Main course (When)—
– Steps showing sequence of interactions
40

21
Use Case Example – Part One
Name—Check Out Album.
Description—Check out a Album for a customer.
Actor—Clerk.
Pre-conditions—The customer has an identification. The
Album has an identity.
Post-conditions—The Album is recorded as rented. The
rental contract is printed.
Main Course:
1. The clerk enters the customer identification and Album identifier
into the system.
2. The system records the information.
3. The system prints a contract that the customer signs.
41
Use Case Template – Part Two
Exceptions: conditions can occur that may not
allow it to reach its post-conditions.
Business Rules: rules that must be followed
regardless of technology
Alternatives: flow that allows the use case to be
successful even if some condition occurs
Note: Alternatives and Exceptions could become
separate story(ies) if significant effort
Exceptions and Alternatives numbered with
reference to Main Course steps
42

22
Use Case Example – Part Two
Exceptions:
1a. Customer identification is not recognized.
Clerk repeats step 1.
1b. The customer violates the Album Rental Limit business rule.
The clerk notifies the customer of the violation.
The use case is abandoned.
Business Rule:
Album Rental Limit
A customer can rent only three Albums at any one time.
Alternatives
3a. The printer jams.
The clerk fills out the contract by hand.
The use case exits.
43
Exercise (Optional)
Write a use case for one of the stories

23
45 7 November 2016
Scenarios
Acceptance Tests
Scenario Examples
Rent a Album—Main course.
Bad Customer ID—Enter customer ID wrong.
Album Rental Limit—Customer has three
Albums and rents another one.
Printer Jam—Simulate printer jam (maybe out
of paper).
46

24
Scenario for a Flow
Initial
System
State
Scenario
Setup
(Given)
Trigger
(When)
Assert
(Then)
Action or Event
Expected
System
State and
Output
Test Flow
Initial
System
State
Test
Setup
(Given)
Trigger
(When)
Assert
(Then)
Final
System
State and
Output
Action or Event
Expected
System
State and
Output
Compare

25
Given / When / Then Example Scenario
Given (Setup)
Customer has ID (initial system state)
Album has ID (initial system state)
Album is not currently rented (initial system state)
When (Trigger)
Clerk checks out Album (action)
Then (Assert)
Album recorded as rented (final system state)
Rental contract printed (output)
Full Example Flow Test (1)
Check Out Album
Given Customer has ID
and Album has ID
and Album is not currently rented
Customer Data
Name ID
James 007
Album Data
ID Title Rented
A2 Beatles Greatest Hits No
Data Tables

26
When a clerk checks out an Album:
Check Out Album
Enter Customer ID 007
Enter Album ID A2
Execute Rent
Action Table
Then the Album is recorded as rented
and a rental contract is printed:
Album Data
ID Title Rented Customer ID
A2 Beatles Greatest Hits Yes 007
Rental Contract
Customer ID Customer Name
Album
ID
Album Title
007 James A2 Beatles Greatest Hits
Anything else on the contract?
Data Tables

27
Full Example – Extended
Given
When a clerk checks out an Album on:
Then a rental contract is printed:
Rental Contract
Customer ID Customer Name
Album
ID
Album Title Due Fee
007 James A2 Beatles Greatest Hits 1/3/2014 $3
Rental Fee Business Rule
Fee
$3
Today
1/1/2014
Rental Time Business Rule
Time
2 days
Exercise (Optional)
Write an acceptance test for your story

28
55 7 November 2016
This is Not an
Ending But a
Beginning
Requirement Layer Review
Big Picture Project, Theme, Epic
Releasable Unit MBI (Minimum
Business Increment),
MVF
Developable Unit Story
Requirement
Details
Use Case Scenarios
Acceptance Tests

29
info@netobjectives.com
www.netobjectives.com
Go Forth and
Become Agile
Thank you
Please fill out evaluations
For more information:
acceptancetestdrivendevelopment.com

Agile Requirements—From Breadth to Depth

Recommended

Recommended

More Related Content

What's hot

What's hot (7)

Similar to Agile Requirements—From Breadth to Depth

Similar to Agile Requirements—From Breadth to Depth (20)

More from TechWell

More from TechWell (20)

Recently uploaded

Recently uploaded (20)

Agile Requirements—From Breadth to Depth