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 - [email protected] - http://www.stareast.techwell.com/

mailto:[email protected]

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 [email protected]

Agile Requirements February, 2007

1

[email protected]

www.netobjectives.com

1 Copyright © 2007 Net Objectives. All Rights Reserved. 7 November 2016

Agile Requirements

From Breadth to Depth

Ken Pugh

[email protected]

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 EventExpected

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 NameAlbum

IDAlbum 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 NameAlbum

IDAlbum 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

[email protected]

www.netobjectives.com


Go Forth and

Become Agile

Thank you

Please fill out evaluations

For more information:

[email protected]

acceptancetestdrivendevelopment.com