user stories the whole story -...

1

User Stories - 1 Copyright 2011 Gerard MeszarosIndia Tour 2011

User StoriesThe Whole Story

Gerard [email protected]


I.T.

EmbeddedTelecom

My Background

Gerard [email protected]

•Software developer

•Development manager

•Project Manager

•Software architect

•OOA/OOD Mentor

•XP/TDD Mentor

•Agile PM Mentor

•Test Automation Consultant

•Author

•Lean/Agile Coach/Consultant

2


Agenda• Introductions• Why User Stories

– Continuous Flow of Value– Good User Stories

• Keeping Stories Small• Specifying User Stories• Verifying User Stories• Deploying User Stories• Conclusions


A User Story is …… a unit of work to develop functionality that:• Is very specific (has concrete examples)• Provides value to the customer• Can be tested independently of other (later)

features• Can be finished in a single iteration… consists of 3 major components:

Story Card + Conversation + Story Tests

3


Sample Story Card

A user can generate invoicesfor all customers in a single

billing cycle


Sample Story Card

Generate invoices for onebilling cycle

4


No, but that’s an interestingidea. We could use that to …

Can more than one BillingCycle have the same dayof the month associated

with it?

Sample Conversation

What’s a BillingCycle

A Billing Cycle is a way togroup Customers who all havetheir invoice generated on the

same day of the month.So each Billing

Cycle has a day ofthe month

associated with it?

That’s right.

Can it be any day ofthe month?

In theory it could be. But inpractice, we find one cycle each

week is enough …


Sample Story Tests

We’ll have lots of examples later!

5


User Stories an Alternative to WBS

• Stories are an alternative to Work BreakdownStructure (WBS) of traditional project plans:

Analysis Design Coding TestingActivity

Module Module ModuleFeatureFeatureFeature

Functionality

Analysis Design Coding TestingActivity

Story 1 Story 2 Story 3Functionality

• Feature Breakdown Structure:

On agile projects, we define the project plan in terms of what will bedelivered rather than what work steps will be performed

Time ->

Time ->


Investing in Good User Stories• Independent

• Negotiable

• Valuable

• Estimatable

• Small

• Testable

• Allows intelligent prioritization

• Enables simplification & elimination

• The “R” of ROI

• The “I” of ROI

• Enables Continuous Flow

• Helps us know when we’re done!Minimum 1

testcase per StoryCourtesy of William Wake

6


Agenda• Introductions• Why User Stories• Keeping Stories Small

– Splitting– Merging– Story-o-types

• Specifying & Verifying User Stories• Deploying User Stories• Conclusions


• Unmanageable without a detailed work breakdown

• Only ready for testing late in sprint• May “surf” into next sprint

• Back-end load the testing effort

TestDevtReqt

TestDevtReqt

Large Stories

Req’t Init Study HLD Design Code Dev.Test Integ.Test IVV FinishedR1.1.1 x x x xR1.1.2 x x x xR1.2.1 x x x x xR1.2.4 x x x x x x x x

Wait, Wait, Hurray Up!

Sprint n Sprint n+1Sprint n-1

7


Small Stories:• Enable Continuous Delivery of Value

• Ensure less work spills into next sprint• Are easier to estimate• Facilitate release/iteration planning• Spreads testing work throughout Sprint

TestDevtReqt

TestDevtReqt

TestDevtReqt

TestDevtReqtSprint n Sprint n+1Sprint n-1

TestDevtReqt

TestDevtReqt


Getting Story Granularity Right• Right-sizing is major challenge for agile teams

• Need to split a story into smaller stories when:– Too large to build in one iteration– Too large to estimate confidently– Various parts have different business value– Various parts have different likelihood of change

• Need to merge Stories when:– Cannot be built or tested independently– Too small to bother managing separately

8


“Right-Sizing” Using StoryOTypesStoryOTypes are “Story Stereotypes”:• Heuristics for decomposing requirements into

smaller user stories• Use as guidelines for identifying different

kinds of functionality in stories• Use as guidelines for combining story

fragments into cohesive stories

NF

UIVBR

AS

http://storyotypespaper.gerardmeszaros.com/


Four Common StoryotypesNF -- New Basic Functionality

– Automates the main scenario of a TX with minimal user interface

AS -- Alternate Scenario– Automates alternate scenario of TX (variation of functionality)

BR -- Business Rule– Defines some algorithm or rule and provides handling for when rule

is broken

UIV -- User Interface Variation– Changes the user interface in some way– usually makes it fancier, but could just provide a different way to do

the same thing

NF

UIVBR

AS

9


Mega Bank Requirements• Notify user of transactions against their

accounts.• User can configure threshold amount for

notification based on any/all of account,transaction type or region, charge category

• Notification can be sent via e-mail, voice-mailor SMS/IM

• User can suspend notifications indefinitely orfor a defined period of time.

Example:


Mega Bank Use CasesExample:

Configure NotificationThreshold

Suspend Notification

Resume NotificationAccountHolder

Process Transaction(possibly notifying user)

TransactionSettlement

10


New Functionality Stories• Basic Notification – Configure notification

threshold and process a transaction– Single threshold for all locations, tx types/categories on

all accounts• Suspend & Resume Notification

– Temporarily disable a configured notification withoutdeleting it. User can enable later.

Some value is provided as soon as these are “Done”Overall system architecture and performance can be verified

NF

Example:


Alternate Scenario Story Groups(and Affected Use Cases)

• Notification Threshold (Configure/Process Tx)• Means of Notification (Configure/Process Tx)• Suspend Notification (Configure/Process Tx)• Resume Notification (Configure/Process Tx)

Example:

AS

11


AS Stories – Configure Threshold• Unauthorized User• User has no accounts registered• Threshold for single account• Threshold for subset of accounts• Threshold for single transaction type

– E.g. Credit, Debit, Inquiry

• Threshold for several transaction types• Threshold for single transaction category

– Eg. One of Travel, Personal, Business

• Threshold for several transaction categories

AS

Example:


AS Stories -- Means of Notification• Notification can be via e-mail

– Configure as e-mail notification and verify e-mail is sent forqualifying transactions

• Notification can be via voice-mail– Configure as voice-mail notification and verify voice-mail is sent for

qualifying transactions

• Notification can be via SMS/IM– Configure as SMS notification and verify SMS is sent for qualifying

transactions

• Notification via several means simultaneously– Configure severals means and verify all are carried out

AS

Example:

12


AS Stories -- Suspend Notification• Unauthorized User• User has no active notifications• Notification suspended until end time• Notification suspended for duration• Suspending all notification rules• Suspending subset of rules

AS

Example:


AS Stories -- Resume Notification• Unauthorized User• User has no suspended notifications• Resume notification suspended until end time• Resume notification suspended for duration• Resume one suspended notification rules• Resume all suspended notification rules

AS

Example:

13


Business Rule Stories• Notification based on Region of TX

– E.g. One of NA, SA, AsiaPacific, Africa, Europe• Notification based on sub-region

– E.g. NA has sub-regions USA, Canada, Mexico• Notification based on TX category

– E.g. Travel, Personal, Business• Notification based on TX type

– E.g. Credit, Debit, Inquiry• Notification based on any combination of the

aboveBR

Example:


UI Variation Stories

Select account(s) for notification/suspensionusing:

• Simple dual list box with add/remove buttons• Multi-selection• Drag & Drop into a “Selected Accounts”

listbox.• Add Accounts to a “Shopping Cart”

UIV

Example:

14


NF

UIVBR

AS

Now What?• Keep These as Our Stories or Combine Them?• Depends on Size, Priority and Stability• May choose to combine them if they are too

small to bother managing separately, and– Same degree of importance, confidence, stability

• Need to combine them if they cannot be testedseparately.– E.g. Suspend & Resume Notification Transactions– E.g. Configure Threshold + Process Tx per BusRule

» One story for each Type, Category, Region


Combining Story Fragments

Configure Threshold for Process TX configured via• Single Charge Category• Several Charge

Categories• Single location• Several Locations• All Locations• Etc.

• Single Charge Category• Several Charge

Categories• Single location• Several Locations• All Locations• Etc.

Example:

Combine Configuration and Processing for eachscenario into a single story• More testable• Provide real value

15


Agenda• Introductions• Why User Stories• Keeping Stories Small• Specifying User Stories

– Why not just “Testing User Stories”– Specifying “Workflows”– Specifying Transactions / Use Cases– Specifying Rules & Calculations

• Verifying User Stories• Deploying User Stories• Conclusions


What the customer thought they wanted

What the customer actually asked for

What the customer realized they actually needed

What development thought the customer asked for

What development actually built

What testing thought the customer asked for

What testing actually tested for

Building the Right Product

16



• How do we eliminatethe waste caused bybuilding the wrongproduct?– Missed requirements?– Misunderstood

requirements?– Unneeded functionality?



• How do we eliminatethe waste caused bybuilding the wrongproduct?– Missed requirements?– Misunderstood

requirements?

17


Example-Driven Development

• A.K.A.– Acceptance Test Driven Development– Behaviour-Driven Development– Executable Specification– StoryTest-Driven Development

• Concrete examples flesh out requirements

• Testers flush out missed scenarios......before development starts


Story Specification at Right Level• Specify broad scope at minimum detail

– E.g. Use least detail when specifying workflow• Specify most detailed req’ts at narrowest

scope– E.g. Don’t use workflow when specifying rules

Make examples/testseasy to understandand easy to write

Narrow BroadScope

Det

ail

Low

High Business

Rules

Workflow

Transactions

Too vagueToo many required

Too much detailUnmaintainable

18


New Functionality: Notification WorkflowUse Case:

ManageNotificationThresholds

Use Case:Process

Transaction

Use Case:View

Notifications

Example:

Broad Scope; Minimum Detail;


New Functionality: Suspension WorkflowUse Case:

ManageNotificationThresholdsUse Case:

ProcessTransactionUse Case:Suspend

Notification

Use Case:View

Notifications

Use Case:Resume

Notification

Example:

19


GUI for Manage Notifications• May do UI design

for a group ofstories

• Should do usabilitytesting at this point

• Can buildautomated userinterface tests

• Or not!

Example:


Single Transaction TestUse Case:

ManageNotifications

Data to be shown onManage Accounts Tab

Side effect of AddNotification Dialog

Data to be shownon Manage

Notifications Tab

Data to be shown onManage Accounts Tab

Medium Detail; Medium Scope

Example:

20


Business Rule Specs

Configuration Process TransactionThreshold per Charge Type

High Detail; Narrow Scope

Example:


Business Rule Specs

Configuration Process TransactionThreshold per Location

Each Story Has It’s Own Tests

21


Agenda• Introductions• Why User Stories• Keeping Stories Small• Specifying User Stories• Verifying User Stories

– Turning Specs into Tests– Who does what?

• Deploying User Stories• Conclusions


Turning Specs into Tests (using FIT)

• Same script is run for each row of table• Avoids duplication of test script.• Compact summary of input values & results

NotificationRequired``Account Charge Type Amount Notify?

100372 Travel 999.99 No100372 Travel 1000.00 Yes100372 Groceries 264.22 No100372 Groceries 264.23 Yes

expectedNoactual

---Inputs--- Outputs

SUTComponentUnder Test

ResultsDocumentMarked up

TableFit

Library

Fit TestRunner

TableInterpreter

22


Sample Fit Column Fixture

public class NotificationRequired ColumnFixture {

public String account;

public int amount;

public CType chargeType;

public Boolean notify( ) {NotificationRules rules = getRules();return rules.notificationReqd(

account, amount, chargeType);}

}


Test-Driven Architecture

Should weNotify?

DoNotification.

ProcessTransaction

ConfigureNotificationThreshold

NotificationRules

NotificationLog

TransactionInterface

ConfigurationUser

InterfaceWorkflow

Test

23


Test-Driven Architecture

Should weNotify?

DoNotification.

ProcessTransaction


NotificationRules

NotificationLog


ConfigurationUser

Interface

ConfigurationTX Test


Test-Driven Architecture• With the right architecture, automating these

tests is trivial

Should weNotify?

DoNotification.

ProcessTransaction


NotificationRules

NotificationLog


ConfigurationUser

InterfaceNotificationRule Test

NotificationMethod Test

24


What Else Should “Testers” Do?Assuming all the Story Tests are passing,

Testing resources can focus on:• Exploratory Testing

– To find missing requirements, unexpected interactions,etc.

• Deployment & Update Testing– To ensure installation goes smoothly

• Usability Testing• Etc.

I.e. “Real” Testing


Who Does What?• Specifying the

Behaviour• Implementing the

Test Automation• Run the Automated

Tests• Exploratory Testing• Product Acceptance

• Product Owner &Testers

• Developers

• Developers, CI Build,Testers

• Testers• Product Owner

25


Agenda• Introductions• Why User Stories• Keeping Stories Small• Specifying User Stories• Verifying User Stories• Deploying User Stories

– Batch Size– Timing

• Conclusions


Deploying User StoriesRecall: Stories are the Unit of Work for building

the Product• Stories should be tested as soon as they are

finished– Fix deficiencies right away; spread out testing effort

• Stories can be deployed as soon as they aretested– If the overhead of deployment is low enough– When “Time is Money”, deploy immediately!

• Stories may be deployed in batches to reduceoverhead– E.g. Daily, per Sprint or multiple Sprints (i.e. Release)

26


Story Lifecycle Summary

NF

UIVBR

AS

NF

UIVBR

ASASAS

UIV

BRBR

NF

UIVBR

ASASAS

UIV

BRBR

R1

R2

R3

Features Story Fragments Stories ReleasesSpec/Tests


Conclusions• Stories need to be small to enable continuous

flow of value.• Story-o-types can be used to right-size stories• We provide details in Story Specs which we

can then execute as Story Tests• Each story-o-type has a corresponding type of

Spec/Test for elaborating on the requirement• Providing tests up front forces architecture to

support easy test automation• Small stories can be deployed immediately or

in batches.

27


Thank You!Gerard Meszaros

[email protected]://www.xunitpatterns.com

Slides at:http://UserStories.xunitTraining.com

Call me when you:• Want to transition to Agile or Lean• Want to do Agile or Lean better• Want to teach developers how to test• Need help with test automation strategy• Want to improve your test automation

Jolt Productivity Awardwinner - Technical Bookshttp://testingguidance

.codeplex.com/

user stories the whole story -...

Documents