Agile&UserStories&Are&Easy& - Good Requirements · AS1.1 User selects index name from a list of available index names. (See ASX) AS1.2 User inputs search date. AS1.3 User initiates

© Jeffrey Davidson, 2012

Agile User Stories Are Easy

How to Turn Old Fashioned Requirements Into Great User Stories

IIBA Fort Worth Chapter – Oct 15, 2012 Jeffrey Davidson


Contact Information Jeffrey Davidson, CSPO PMC

Principal Consultant,

President, IIBA Dallas

•  email [email protected]

•  blog http://goodrequirements.com

•  Twitter @JeffreyGoodReq


4 Takeaways

Explain: How traditional requirements compare to user stories

Describe: Elements of a good user story

Answer: “What happens to the stuff I used to document?”

Discuss: “Why my teams will love this!”


Simple?

•  “We can only hope to make reliable those things that we can understand.

•  We can only consider a few things at a time.

•  Intertwined things must be considered together.

•  Complexity undermines understanding.”

“Simple Made Easy” by Rich Hickey @ StrangeLoop 2011


Capers Jones

<500 Function Points


Cutter Consortium, Mobile SW Dev

30% Requirements do not reflect needs


Forrester Research

40% Executives Dissatisfied


Standish Group, CHAOS Reports

45% Features Never Used


IT Complexity Crisis

$3 trillion Global impact of IT failures

© Jeffrey Davidson, 2012 © Jeffrey Davidson, 2012


Many forms of Government have been tried and will be tried in this world of sin and woe. No one pretends that democracy is perfect or all-‐wise. Indeed, it has been said that democracy is the worst form of government except all those other forms that have been tried from time to time.

– Winston Churchill © Jeffrey Davidson, 2012


System Requirements Specification

Use Cases

Scope / Product Roadmap

Charter / Vision Business Objectives

Needs

Features

Goal / Usage

Details

Functional & Non-‐functional, Business Rules, Data Models, Process Flows, State Charts,

Activity Diagrams, Report Reqs, Test Cases, Wire Frames, …



Securitization Accounting Release 2 Edit Index Rate

MS10. System determines entered rate is valid. (See AS7)

MS11. System records rate.

MS12. System records System date and time.

MS13. System records User’s identification information.

Alternative Scenarios AS1 User chooses to edit existing rate value.

AS1.1 User selects index name from a list of available index names. (See ASX)

AS1.2 User inputs search date.

AS1.3 User initiates search.

AS1.4 System determines date is valid. (See ASX) (See ASX) (See ASX)

AS1.5 System displays rate value entry screen with existing rate information.

AS1.6 Return to MS8.

AS2 User does not select index name.

AS2.1 User inputs new effective date for rate. (See ASX)

AS2.2 User chooses to input rate value.

AS2.3 System displays rate maintenance screen with all data previously entered by User.

AS2.4 System displays an error message.


AS3 System determines rate already exists for date provided.



AS4 System determines provided date is beyond today’s date.



AS5 System determines provided date is formatted improperly.



AS6 User does not input all rate information.

AS6.1 User indicates that rate entry is complete.

AS6.2 System displays an error message to User.

AS6.3 System displays rate value entry screen with all data previously entered by User.


AS7 System determines rate is invalid.

AS7.1 System displays an error message to User.

AS7.2 System displays rate value entry screen with all data previously entered by User.




System Requirements Specification

Use Cases

Scope / Product Roadmap


Needs

Features

Goal / Usage

Details

Functional & Non-‐functional, Business Rules, Data Models, Process Flows, State Charts,

Activity Diagrams, Report Reqs, Test Cases, Wire Frames, …


Conversation, Acceptance Criteria,

Documentation

User Stories

Epic Stories


Needs

Features

Goal

Details


user stories: what


user story


promise © Jeffrey Davidson, 2012


acceptance criteria © Jeffrey Davidson, 2012





© Jeffrey Davidson, 2012 Sco8 Sehlhorst, h8p://www.tynerblain.com/blog, 2010



user stories: how


independent negotiable valuable

estimate-‐able small testable

INVEST by Bill Wake, www.xp123.com, 2003


independent © Jeffrey Davidson, 2012


negoLable © Jeffrey Davidson, 2012


valuable © Jeffrey Davidson, 2012


esLmate-‐able © Jeffrey Davidson, 2012


small © Jeffrey Davidson, 2012


testable © Jeffrey Davidson, 2012


first: epic stories one user’s viewpoint customer benefit

ui: later sized for the horizon

FOCUS based on User Stories Applied, 2004


first: epic stories © Jeffrey Davidson, 2012


one person’s viewpoint



customer benefit



ui: later © Jeffrey Davidson, 2012


for the horizon sized



user stories: compare



Informal Use Case

Formal Use Case

Use Case Brief User

Story More Less

More

Less

Detail Captured

Doc

umen

tation

Ove

rhea

d


Informal Use Case

Formal Use Case

Use Case Brief

More Less

More

Less

Detail Captured

Doc

umen

tation

Ove

rhea

d


Informal Use Case

Use Case Brief

More Less

More

Less

Detail Captured

Doc

umen

tation

Ove

rhea

d


Securitization Accounting Release 2 Edit Index Rate

Document Info Project Name: Securitization Accounting Release 2 Use Case ID: 008 Use Case Name: Edit Index Rate Related Story Cards:

Change History

Date (yyyy-mm-dd)

Version Description Author

2005-03-30 0.1 Initial Draft Julie 2005-04-07 0.2 Reviewed Draft Adam

Use Case Header Info Description: The Funding Accountant wants to input and store new rates for the month in order to

use them in the revolving transaction funding calculation.

Assumptions: Index rates are available for input from the proper source.

Frequency: Once per month.

Actor(s): Funding Accountant.

Trigger: User receives new rates for the month.

Preconditions: User has logged into the System AND

User has new rate ready to enter into System.

Success End Conditions:

System stores rate and User’s identifying information.

Use Case Story User gets the new index rates for the day from BANK. They then go in to FMS and input the new rate information, including the rate itself and the effective date, into FMS and save the information to the System. User may also choose to view or edit past rates.

Use Case Steps

Main Success Scenario MS1. System displays rate maintenance screen.

MS2. User chooses to create new rate value. (See AS1)

MS3. User selects index name from a list of available index names. (See AS2)

MS4. User inputs new effective date for rate.

MS5. User chooses to input rate value.

MS6. System determines date is valid. (See AS3) (See AS4) (See AS5)

MS7. System displays rate value entry screen.

MS8. User inputs rate information. (See AS6)

MS9. User indicates that rate entry is complete.


=


= ?


= ? ? ?



Communicating with Examples



Behavior Based Requirements

•  Functional Behavior

•  Story format


– – context

You & Your conditi

on

What you do

What you see

Simple Structure

event response


– – Given

You & Your conditi

on

What you do

What you see

Simple Structure

When Then


Helpful Guidelines

Given: I am documenting reqs

When: I write req using business terms

Then: My business partners will understand the req


Helpful Guidelines


When: I write req using design agnostic behavior

Then: My requirements may be reused


Helpful Guidelines


When: I write req using natural language

Then: My requirements will be understood


Helpful Guidelines


When: I add example scenarios with data

Then: I can validate what has been built meets the goals


Power of BBR Comes From . . .

•  Precise grammatical structure

•  Discovery & understanding

•  Captured conversation


Power of BBR Gives . . .

•  Shared Understanding

•  Definition of “Done”

•  Automation enables Continuous Integration

•  Examples enable Living Documentation


– – Given

You & Your conditi

on

What you do

What you see

When Then


Who Benefits?

Everyone!

•  Seriously, it helps everyone •  Sponsors •  Business partners •  Users

•  Testers •  Developers •  Analysts


Ferryboats & Bridges


questions?


Recap •  I N V E S T with F O C U S

•  Document what the job needs

•  Given – When – Then: Communicate with Behavior Based Requirements

•  Everyone will love your your User Stories when you build bridges of understanding


Resources: User Stories Cockburn, Alistair. Wri$ng Effec$ve Use Cases. Addison-‐

Wesley; 2000.

Cohn, Mike. User Stories Applied for Agile So:ware Development. Addison-‐Wesley; 2004.

Go8esdiener, Ellen. The So:ware Requirements Memory Jogger. Goal/QPC; 2005.

Sehlhorst, Sco8. h8p://www.tynerblain.com/blog


Resources: Given – When – Then Gojko Adzic BDD / Specification by Example

gojko.net

Liz Keogh BDD lunivore.com

Chris Matts Invented: Feature Injection theitriskmanager.wordpress.com

Dan North Invented: BDD dannorth.net

Martin Fowler Co-‐invented: Ferryman & Bridge builder martinfolwer.com


Share & Tell

This is licensed under Creative Commons Sharealike [CC BY 3.0]

•  Please use it

•  Please share it

•  Please improve it

•  As long as you credit me somewhere


Agile User Stories Are Easy

How to Turn Old Fashioned Requirements Into Great User Stories

IIBA Fort Worth Chapter – Oct 15, 2012 Jeffrey Davidson

email: [email protected] blog: http://goodrequirements.com

Documents

Agile&UserStories&Are&Easy& - Good Requirements · AS1.1 User selects index name from a list of available index names. (See ASX) AS1.2 User inputs search date. AS1.3 User initiates