Upload
others
View
0
Download
0
Embed Size (px)
Citation preview
1
User Stories - 1 Copyright 2011 Gerard MeszarosIndia Tour 2011
User StoriesThe Whole Story
Gerard [email protected]
User Stories - 2 Copyright 2011 Gerard MeszarosIndia Tour 2011
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
User Stories - 3 Copyright 2011 Gerard MeszarosIndia Tour 2011
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
User Stories - 4 Copyright 2011 Gerard MeszarosIndia Tour 2011
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
User Stories - 5 Copyright 2011 Gerard MeszarosIndia Tour 2011
Sample Story Card
A user can generate invoicesfor all customers in a single
billing cycle
User Stories - 6 Copyright 2011 Gerard MeszarosIndia Tour 2011
Sample Story Card
Generate invoices for onebilling cycle
4
User Stories - 7 Copyright 2011 Gerard MeszarosIndia Tour 2011
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 …
User Stories - 8 Copyright 2011 Gerard MeszarosIndia Tour 2011
Sample Story Tests
We’ll have lots of examples later!
5
User Stories - 9 Copyright 2011 Gerard MeszarosIndia Tour 2011
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 ->
User Stories - 10 Copyright 2011 Gerard MeszarosIndia Tour 2011
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
User Stories - 11 Copyright 2011 Gerard MeszarosIndia Tour 2011
Agenda• Introductions• Why User Stories• Keeping Stories Small
– Splitting– Merging– Story-o-types
• Specifying & Verifying User Stories• Deploying User Stories• Conclusions
User Stories - 12 Copyright 2011 Gerard MeszarosIndia Tour 2011
• 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
User Stories - 13 Copyright 2011 Gerard MeszarosIndia Tour 2011
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
User Stories - 14 Copyright 2011 Gerard MeszarosIndia Tour 2011
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
User Stories - 15 Copyright 2011 Gerard MeszarosIndia Tour 2011
“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/
User Stories - 16 Copyright 2011 Gerard MeszarosIndia Tour 2011
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
User Stories - 17 Copyright 2011 Gerard MeszarosIndia Tour 2011
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:
User Stories - 18 Copyright 2011 Gerard MeszarosIndia Tour 2011
Mega Bank Use CasesExample:
Configure NotificationThreshold
Suspend Notification
Resume NotificationAccountHolder
Process Transaction(possibly notifying user)
TransactionSettlement
10
User Stories - 19 Copyright 2011 Gerard MeszarosIndia Tour 2011
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:
User Stories - 20 Copyright 2011 Gerard MeszarosIndia Tour 2011
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
User Stories - 21 Copyright 2011 Gerard MeszarosIndia Tour 2011
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:
User Stories - 22 Copyright 2011 Gerard MeszarosIndia Tour 2011
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
User Stories - 23 Copyright 2011 Gerard MeszarosIndia Tour 2011
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:
User Stories - 24 Copyright 2011 Gerard MeszarosIndia Tour 2011
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
User Stories - 25 Copyright 2011 Gerard MeszarosIndia Tour 2011
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:
User Stories - 26 Copyright 2011 Gerard MeszarosIndia Tour 2011
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
User Stories - 27 Copyright 2011 Gerard MeszarosIndia Tour 2011
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
User Stories - 28 Copyright 2011 Gerard MeszarosIndia Tour 2011
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
User Stories - 29 Copyright 2011 Gerard MeszarosIndia Tour 2011
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
User Stories - 30 Copyright 2011 Gerard MeszarosIndia Tour 2011
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
User Stories - 31 Copyright 2011 Gerard MeszarosIndia Tour 2011
Building the Right Product
• How do we eliminatethe waste caused bybuilding the wrongproduct?– Missed requirements?– Misunderstood
requirements?– Unneeded functionality?
User Stories - 32 Copyright 2011 Gerard MeszarosIndia Tour 2011
Building the Right Product
• How do we eliminatethe waste caused bybuilding the wrongproduct?– Missed requirements?– Misunderstood
requirements?
17
User Stories - 33 Copyright 2011 Gerard MeszarosIndia Tour 2011
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
User Stories - 34 Copyright 2011 Gerard MeszarosIndia Tour 2011
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
User Stories - 35 Copyright 2011 Gerard MeszarosIndia Tour 2011
New Functionality: Notification WorkflowUse Case:
ManageNotificationThresholds
Use Case:Process
Transaction
Use Case:View
Notifications
Example:
Broad Scope; Minimum Detail;
User Stories - 36 Copyright 2011 Gerard MeszarosIndia Tour 2011
New Functionality: Suspension WorkflowUse Case:
ManageNotificationThresholdsUse Case:
ProcessTransactionUse Case:Suspend
Notification
Use Case:View
Notifications
Use Case:Resume
Notification
Example:
19
User Stories - 37 Copyright 2011 Gerard MeszarosIndia Tour 2011
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:
User Stories - 38 Copyright 2011 Gerard MeszarosIndia Tour 2011
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
User Stories - 39 Copyright 2011 Gerard MeszarosIndia Tour 2011
Business Rule Specs
Configuration Process TransactionThreshold per Charge Type
High Detail; Narrow Scope
Example:
User Stories - 40 Copyright 2011 Gerard MeszarosIndia Tour 2011
Business Rule Specs
Configuration Process TransactionThreshold per Location
Each Story Has It’s Own Tests
21
User Stories - 41 Copyright 2011 Gerard MeszarosIndia Tour 2011
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
User Stories - 42 Copyright 2011 Gerard MeszarosIndia Tour 2011
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
User Stories - 43 Copyright 2011 Gerard MeszarosIndia Tour 2011
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);}
}
User Stories - 44 Copyright 2011 Gerard MeszarosIndia Tour 2011
Test-Driven Architecture
Should weNotify?
DoNotification.
ProcessTransaction
ConfigureNotificationThreshold
NotificationRules
NotificationLog
TransactionInterface
ConfigurationUser
InterfaceWorkflow
Test
23
User Stories - 45 Copyright 2011 Gerard MeszarosIndia Tour 2011
Test-Driven Architecture
Should weNotify?
DoNotification.
ProcessTransaction
ConfigureNotificationThreshold
NotificationRules
NotificationLog
TransactionInterface
ConfigurationUser
Interface
ConfigurationTX Test
User Stories - 46 Copyright 2011 Gerard MeszarosIndia Tour 2011
Test-Driven Architecture• With the right architecture, automating these
tests is trivial
Should weNotify?
DoNotification.
ProcessTransaction
ConfigureNotificationThreshold
NotificationRules
NotificationLog
TransactionInterface
ConfigurationUser
InterfaceNotificationRule Test
NotificationMethod Test
24
User Stories - 47 Copyright 2011 Gerard MeszarosIndia Tour 2011
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
User Stories - 48 Copyright 2011 Gerard MeszarosIndia Tour 2011
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
User Stories - 49 Copyright 2011 Gerard MeszarosIndia Tour 2011
Agenda• Introductions• Why User Stories• Keeping Stories Small• Specifying User Stories• Verifying User Stories• Deploying User Stories
– Batch Size– Timing
• Conclusions
User Stories - 50 Copyright 2011 Gerard MeszarosIndia Tour 2011
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
User Stories - 51 Copyright 2011 Gerard MeszarosIndia Tour 2011
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
User Stories - 52 Copyright 2011 Gerard MeszarosIndia Tour 2011
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
User Stories - 53 Copyright 2011 Gerard MeszarosIndia Tour 2011
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/