Top Banner
User Stories User Stories James Peckham (Extracted James Peckham (Extracted from Mike Cohn’s Book from Mike Cohn’s Book “User Stories Applied”) “User Stories Applied”)
122
Welcome message from author
This document is posted to help you gain knowledge. Please leave a comment to let me know what you think about it! Share it to your friends and learn new things together.
Transcript
Page 1: User Stories

User StoriesUser Stories

James Peckham (Extracted James Peckham (Extracted from Mike Cohn’s Book “User from Mike Cohn’s Book “User

Stories Applied”)Stories Applied”)

Page 2: User Stories

Customer TeamCustomer Team

(Acceptance) Testers(Acceptance) Testers Product managerProduct manager Real usersReal users Interaction designersInteraction designers

Page 3: User Stories

DeveloperDeveloper

DBADBA Technical Writer (Documentation)Technical Writer (Documentation) ProgrammerProgrammer Build master/wranglerBuild master/wrangler

Page 4: User Stories

What is a user story?What is a user story?

CardCard ConversationConversation ConfirmationConfirmation

Page 5: User Stories

Where are the details?Where are the details?

One thing to say, another to code One thing to say, another to code and test…and test… I want to post jobsI want to post jobs

Additional stories?Additional stories? Confirmation through tests!Confirmation through tests!

Page 6: User Stories

What do I writeWhat do I write

ThemeTheme I want a Job boardI want a Job board

EpicEpic StoryStory

Page 7: User Stories

EpicEpic

A user can search for a jobA user can search for a job A company can post job openingsA company can post job openings

Page 8: User Stories

StoryStory

A user can search for jobs by attributes A user can search for jobs by attributes like location, salary range, job title, like location, salary range, job title, company name, and the date the job company name, and the date the job was postedwas posted

A user can view information about each A user can view information about each job that is matched by a searchjob that is matched by a search

A user can view detailed information A user can view detailed information about a company that has posted a jobabout a company that has posted a job

Page 9: User Stories

What do I Write?What do I Write?

Don’t have to go this farDon’t have to go this far A user can view a job descriptionA user can view a job description A user can view jobs salary rangeA user can view jobs salary range A user can view the location of a jobA user can view the location of a job

Don’t have to do requirements styleDon’t have to do requirements style 4.6)A user can view information about each 4.6)A user can view information about each

job that is matched by a searchjob that is matched by a search 4.6.1) a user can view the job description4.6.1) a user can view the job description 4.6.2) a user can view a job’s salary range.4.6.2) a user can view a job’s salary range. 4.6.3) a user can view the location of a job4.6.3) a user can view the location of a job

Page 10: User Stories

What is the process like?What is the process like?

Not like waterfallNot like waterfall User/Proxy can’t just say what the stories User/Proxy can’t just say what the stories

are then go away.are then go away. Users/Proxy should Play active role in Users/Proxy should Play active role in

writing storieswriting stories Why wouldn’t you want to be involved with Why wouldn’t you want to be involved with

writing the stories?writing the stories? Written in language of the business instead of Written in language of the business instead of

tech jargon. (this will help with prioritization tech jargon. (this will help with prioritization and choosing of stories for planning releases)and choosing of stories for planning releases)

Page 11: User Stories

How long does it have to How long does it have to be?be?

On the back of the card a reminder On the back of the card a reminder for testsfor tests Try with empty job descriptionTry with empty job description Try with a really long job descriptionTry with a really long job description Try with missing salaryTry with missing salary Try with six digit salaryTry with six digit salary

Page 12: User Stories

When do we write them?When do we write them?

Story writing workshopStory writing workshop During demoDuring demo Any time you want!Any time you want!

Get business language! (easy to read, Get business language! (easy to read, no technical jargon!)no technical jargon!)

Page 13: User Stories

Planning releasesPlanning releases

Guess velocity for first iteration!Guess velocity for first iteration! Choose iteration length 1-4 weeksChoose iteration length 1-4 weeks Arrange stories into releases.Arrange stories into releases.

Page 14: User Stories

What are acceptance What are acceptance tests?tests?

Write tests early as possibleWrite tests early as possible Communicate earlier such asCommunicate earlier such as

A user can pay for the items in her shopping A user can pay for the items in her shopping cart with a credit cardcart with a credit card

Test with visa, MC, Amex (pass).Test with visa, MC, Amex (pass). Test with diners club (fail)Test with diners club (fail) Test with visa debit card (pass)Test with visa debit card (pass) Test with good, bad and missing ID numbers Test with good, bad and missing ID numbers

from back of cardfrom back of card Test with expired cardsTest with expired cards Test with different purchase amounts (including Test with different purchase amounts (including

over limit)over limit)

Page 15: User Stories

Why?Why?

Emphasize verbal rather than written Emphasize verbal rather than written communication (proven better!)communication (proven better!)

User stories comprehensible by both users User stories comprehensible by both users and developersand developers

Right size for planning and estimatingRight size for planning and estimating Work for iterative and incremental Work for iterative and incremental

developmentdevelopment Encourage deferring the detail until you Encourage deferring the detail until you

have the best understanding of what you have the best understanding of what you really need.really need.

Page 16: User Stories

Writing StoriesWriting Stories

Chapter 2Chapter 2

Page 17: User Stories

INVESTINVEST

IndependentIndependent NegotiableNegotiable Valuable to users or customersValuable to users or customers EstimableEstimable SmallSmall TestableTestable

Page 18: User Stories

IndependentIndependent Care taken to introduce as little dependencies as Care taken to introduce as little dependencies as

possible.possible. BADBAD

Company can pay for a job posting with a visa cardCompany can pay for a job posting with a visa card Company can pay for a job posting with a master cardCompany can pay for a job posting with a master card Company can pay for a job posting with an American Company can pay for a job posting with an American

ExpressExpress GoodGood

Company can pay for a job posting with a credit cardCompany can pay for a job posting with a credit card Also goodAlso good

Company can pay for a job posting with one type of a credit Company can pay for a job posting with one type of a credit cardcard

Company can pay for a job posting with two additional types Company can pay for a job posting with two additional types of credit cardsof credit cards

Last resortLast resort Two estimates on the card i.e. 8/3Two estimates on the card i.e. 8/3

Page 19: User Stories

NegotiableNegotiable

Not contractsNot contracts Tough to include Just enough detailTough to include Just enough detail Putting note at the bottom of card, Putting note at the bottom of card,

but leaving it open to be negotiable.but leaving it open to be negotiable. Mistake extra detail as extra precision Mistake extra detail as extra precision

and forget the conversation.and forget the conversation. A phrase to remind for conversationA phrase to remind for conversation A note or two to remind for any A note or two to remind for any

further negotiation/issues.further negotiation/issues.

Page 20: User Stories

Valuable to purchasers Valuable to purchasers or usersor users

Throughout the development process, the Throughout the development process, the development team will produce documentation development team will produce documentation suitable for an ISO 9001 audit. -- purchasersuitable for an ISO 9001 audit. -- purchaser

NotNot All connections to the database are through a All connections to the database are through a

connection poolconnection pool All error handling and logging is done through a set of All error handling and logging is done through a set of

common classes.common classes. If there’s a technical story put it in terms the If there’s a technical story put it in terms the

business can understandbusiness can understand Up to fifty users should be able to use the application Up to fifty users should be able to use the application

with a five-user database licensewith a five-user database license All errors are presented to the user and logged in a All errors are presented to the user and logged in a

consistent manner.consistent manner.

Page 21: User Stories

EstimableEstimable

Common reasons why they’re notCommon reasons why they’re not Lack domain knowledgeLack domain knowledge

Can discuss with business people and learnCan discuss with business people and learn Lack technical knowledgeLack technical knowledge

Can spike on the story to learn more about itCan spike on the story to learn more about it Two stories, one for the spike one for the real workTwo stories, one for the spike one for the real work

Story is too bigStory is too big Sometimes useful to write the epic to be a Sometimes useful to write the epic to be a

placeholder for some glossed over part of a system.placeholder for some glossed over part of a system. Pulled from thin air estimate!Pulled from thin air estimate!

Or break it down.Or break it down.

Page 22: User Stories

SmallSmall

Size does matterSize does matter A user can plan a vacation (EPIC)A user can plan a vacation (EPIC)

Based on team and capabilities and Based on team and capabilities and technology in use.technology in use.

Compound or complex Epic stories.Compound or complex Epic stories. Too much for a slide… page 24Too much for a slide… page 24

Page 23: User Stories

TestableTestable User must find the software easy to use.User must find the software easy to use.

A novice user is able to complete common A novice user is able to complete common workflows without trainingworkflows without training

A user must not have to wait long for a A user must not have to wait long for a screen to appear.screen to appear. New screens appear within two seconds in New screens appear within two seconds in

95% of all cases.95% of all cases. Strive for 99% automationStrive for 99% automation Automate on the code not just the UI.Automate on the code not just the UI.

Fit is goodFit is good NUnit is goodNUnit is good

Page 24: User Stories

User role User role ModelingModeling

Chapter 3Chapter 3

Page 25: User Stories

User RolesUser Roles

ExamplesExamples Job SeekerJob Seeker EmployerEmployer AdministratorAdministrator Helpdesk agentHelpdesk agent

Page 26: User Stories

stepssteps

Brainstorm initial setBrainstorm initial set Organize setOrganize set Consolidate the rolesConsolidate the roles Refine the rolesRefine the roles

Page 27: User Stories

Brainstorming rolesBrainstorming roles

Before any project (before any Before any project (before any theme of stories)theme of stories)

Grab stack of cardsGrab stack of cards TimeboxTimebox Write as many names of people and Write as many names of people and

their role in using the software.their role in using the software. 15min or less usually.15min or less usually.

Page 28: User Stories

Organize cardsOrganize cards

Find the description of a higher Find the description of a higher grouping and start filtering into grouping and start filtering into those groups all the cards.those groups all the cards.

Arrange on a table.Arrange on a table.

Page 29: User Stories

Consolidate rolesConsolidate roles

Read any that sound similar. If it’s Read any that sound similar. If it’s redundant find a common name and redundant find a common name and remove the extras.remove the extras.

If there’s no reason to distinguish, If there’s no reason to distinguish, remove.remove.

Page 30: User Stories

Refine rolesRefine roles Attributes worth considering in Attributes worth considering in

distinguishing from one role to anotherdistinguishing from one role to another Frequency with which the user will use Frequency with which the user will use

softwaresoftware Users level of expertise with the domainUsers level of expertise with the domain Users general level of proficiency with Users general level of proficiency with

computers and softwarecomputers and software Users level of proficiency with the software Users level of proficiency with the software

being developedbeing developed General goal for using the softwareGeneral goal for using the software

Rich experience,Rich experience, ConvenienceConvenience

Page 31: User Stories

optional techniques for optional techniques for rolesroles

PersonasPersonas Mario works as a recruiter in the Mario works as a recruiter in the

personnel department of speedy personnel department of speedy networks, a manufacturer of high end …. networks, a manufacturer of high end …. etcetc

Extreme characters Extreme characters Consider a PDA for:Consider a PDA for:

BMW driving management consultantBMW driving management consultant The popeThe pope Drug dealerDrug dealer

Page 32: User Stories

Gathering storiesGathering stories

chapter4chapter4

Page 33: User Stories

TrawlingTrawling

Big wide net, get all the big fish.Big wide net, get all the big fish. Then start casting smaller nets.Then start casting smaller nets. Why isn’t little enough?Why isn’t little enough?

Prescriptive process feel…Prescriptive process feel… Can evolve from the epic to more Can evolve from the epic to more

stories later on!stories later on!

Page 34: User Stories

techniquestechniques

User interviewsUser interviews QuestionnairesQuestionnaires ObservationObservation Story-writing workshopsStory-writing workshops

Page 35: User Stories

interviewsinterviews

Real users when possibleReal users when possible You build what I asked for but that’s You build what I asked for but that’s

not what I want!not what I want! Just because they have the Just because they have the

knowledge doesn’t mean they know knowledge doesn’t mean they know the way to implementthe way to implement Complex mini-language lesson-Complex mini-language lesson- visual visual

designer instead.designer instead.

Page 36: User Stories

Open ended and context Open ended and context free questionsfree questions

Would you like that app to be in a Would you like that app to be in a browser?browser?

Would you like our new app in a browser Would you like our new app in a browser rather than a native windows application rather than a native windows application even if it means reduced performance, even if it means reduced performance, poorer overall user experience, and less poorer overall user experience, and less interactivity?interactivity?

How fast do searches need to be? How fast do searches need to be? What performance is required? Is What performance is required? Is

performance more important in some performance more important in some parts of the application?parts of the application?

Page 37: User Stories

QuestionnairesQuestionnaires

Gather info on stories from bigger Gather info on stories from bigger user baseuser base

Large number of answers for a Large number of answers for a specific questionspecific question

BadBad ““What features would you like to see”What features would you like to see”

Miss things if you give them a multiple Miss things if you give them a multiple choicechoice

Hard to tabulate if open textHard to tabulate if open text

Page 38: User Stories

Story Writing WorkshopsStory Writing Workshops WhoWho

DevelopersDevelopers UsersUsers Product customerProduct customer Other stakeholdersOther stakeholders

Low fidelity prototypingLow fidelity prototyping whiteboard,whiteboard, Note cardsNote cards PaperPaper

Component layoutComponent layout Throw away the low-fidelity prototype!Throw away the low-fidelity prototype! Access competitive products if you’re stuck!Access competitive products if you’re stuck!

Page 39: User Stories

Developer Developer responsibilitiesresponsibilities

Understand and use multiple Understand and use multiple techniques while trawlingtechniques while trawling

Make best use of open ended and Make best use of open ended and context free questionscontext free questions

Page 40: User Stories

Customer Customer responsibilitiesresponsibilities

Understand and use multiple techniques Understand and use multiple techniques while trawling for storieswhile trawling for stories

Writing as many stories as early as possibleWriting as many stories as early as possible Main representative of the software and Main representative of the software and

responsible for options in communicating responsible for options in communicating with themwith them

If you need or want help responsible for If you need or want help responsible for scheduling and running story writing scheduling and running story writing workshopsworkshops

Responsible for making sure all roles are Responsible for making sure all roles are appropriately representedappropriately represented

Page 41: User Stories

Working with Working with user proxiesuser proxies

Chapter 5Chapter 5

Page 42: User Stories

Selecting user proxiesSelecting user proxies It’s difficult to get all the right real usersIt’s difficult to get all the right real users

But important to try!But important to try! Can’t get our user because of their Can’t get our user because of their

manager (a helpdesk, NOC, etc)manager (a helpdesk, NOC, etc) Bring manager inBring manager in CorroborateCorroborate

Development manager = worst proxy Development manager = worst proxy possible! possible!

Sales Person = bad proxy but great way Sales Person = bad proxy but great way to get introduced to good users.to get introduced to good users.

Page 43: User Stories

Domain expertsDomain experts

Great domain modelersGreat domain modelers Can put definitions to unique domain Can put definitions to unique domain

languagelanguage Identify business rulesIdentify business rules

Real user betterReal user better For interactions with the softwareFor interactions with the software

Page 44: User Stories

Marketing groupMarketing group

Focus on quantity of features rather Focus on quantity of features rather than the quality of those featuresthan the quality of those features

Might not have insight to provide Might not have insight to provide detail about those stories*detail about those stories*

Page 45: User Stories

Former UsersFormer Users

Experience will expire!Experience will expire!

Page 46: User Stories

CustomersCustomers

Buyers not necessarily users!Buyers not necessarily users!

Page 47: User Stories

Trainers and tech Trainers and tech supportsupport

Ease of trainingEase of training Ease of supportingEase of supporting Good goals, but what’s important?Good goals, but what’s important?

Page 48: User Stories

Business or System Business or System analystanalyst

One foot in tech one foot in the One foot in tech one foot in the domain.domain.

Tendency to be forced into thinking Tendency to be forced into thinking the problem out instead of getting the problem out instead of getting the information from the users.the information from the users.

3 weeks to figure out a story instead 3 weeks to figure out a story instead of a 2 hour session.*of a 2 hour session.*

Page 49: User Stories

What to do when working What to do when working with proxywith proxy

When users exist but access is limitedWhen users exist but access is limited User task force story writers under a proxyUser task force story writers under a proxy

When there is no user availableWhen there is no user available Use more than oneUse more than one Competing productsCompeting products Reviews of their productsReviews of their products

Can you do it yourself?Can you do it yourself? Avoid it!Avoid it!

Developers won’t have the ‘closeness’ with user-baseDevelopers won’t have the ‘closeness’ with user-base Even if Developers are the users!Even if Developers are the users!

Especially if the Developers are the users! Cherry pick!Especially if the Developers are the users! Cherry pick!

Constituting the Customer teamConstituting the Customer team Put real users on the customer team!Put real users on the customer team!

Page 50: User Stories

Dev responsibilitiesDev responsibilities

Organize and select appropriate Organize and select appropriate customercustomer

Understand how different user Understand how different user proxies can affect the system being proxies can affect the system being built and influence the interactions.built and influence the interactions.

Page 51: User Stories

Customer Customer ResponsibilitiesResponsibilities

If you’re not the user, know the If you’re not the user, know the proxy type that describes you!proxy type that describes you!

Understand what biases you may Understand what biases you may bring to the table and work towards bring to the table and work towards overcoming them.overcoming them.

Page 52: User Stories

Acceptance Acceptance Testing User Testing User

StoriesStoriesChapter 6Chapter 6

Page 53: User Stories

Write tests before codingWrite tests before coding

When?When? Capture specific details when talkingCapture specific details when talking At the start of the iteration before programming At the start of the iteration before programming

beginsbegins When new tests are discovered after the When new tests are discovered after the

programming of a storyprogramming of a story ConsiderationsConsiderations

What else would a programmer need?What else would a programmer need? What am I assuming?What am I assuming? Are there circumstances where this story will be Are there circumstances where this story will be

different?different? What could go wrong?What could go wrong?

Page 54: User Stories

Customer Team Specifies Customer Team Specifies teststests

Because it’s their vision!Because it’s their vision! They can work with a programmer They can work with a programmer

to create the tests.to create the tests. Testers can augment the tests of Testers can augment the tests of

course to better suite the need.course to better suite the need.

Page 55: User Stories

Testing is part of the Testing is part of the processprocess

Not something you do “At the end”Not something you do “At the end” Testers can’t learn of the system Testers can’t learn of the system

from the programmers.from the programmers. In the processIn the process

Write a testWrite a test Write code to support the testWrite code to support the test Think of more tests.Think of more tests.

Page 56: User Stories

How many are too many?How many are too many?

Continue to write as long as they Continue to write as long as they add value or clarity to the story.add value or clarity to the story.

Good programming teams will have Good programming teams will have Unit Tests in place that handle low Unit Tests in place that handle low level things.level things. i.e. feb 30i.e. feb 30thth not a real date not a real date

Page 57: User Stories

Framework Integrated Framework Integrated TestTest

Spreadsheet/data table testsSpreadsheet/data table tests Action testsAction tests Requires test harness development Requires test harness development

(a programmer)(a programmer) Requires decoupling from User Requires decoupling from User

interfaceinterface FitnesseFitnesse

Wiki based execution of FIT testsWiki based execution of FIT tests

Page 58: User Stories

Types of testsTypes of tests

Mike Cohn’s ‘reason’ listMike Cohn’s ‘reason’ list User interface tests User interface tests Usability testingUsability testing Performance testingPerformance testing Stress TestingStress Testing

Crystal Clear ‘how’ ListCrystal Clear ‘how’ List GUI based acceptance (Expensive and GUI based acceptance (Expensive and

slow)slow) GUI-less acceptanceGUI-less acceptance Unit TestsUnit Tests

Page 59: User Stories

Developer Developer responsibilitiesresponsibilities

AutomatingAutomating Thinking of additional testsThinking of additional tests Unit testing code so acceptance Unit testing code so acceptance

tests don’t need specified for low tests don’t need specified for low hanging fruithanging fruit

Page 60: User Stories

Customer Team Customer Team ResponsibilitiesResponsibilities

Responsible for acceptance testsResponsible for acceptance tests Responsible for executing testsResponsible for executing tests

Page 61: User Stories

Guidelines for Guidelines for good storiesgood stories

Chapter 7Chapter 7

Page 62: User Stories

Start with goal storiesStart with goal stories

Search for jobsSearch for jobs Automate search process so she Automate search process so she

doesn’t have to search manually doesn’t have to search manually each timeeach time

Make her resume available so that Make her resume available so that companies may search for hercompanies may search for her

Easily apply for any jobs she likesEasily apply for any jobs she likes

Page 63: User Stories

Slice the cakeSlice the cake When there’s a large storyWhen there’s a large story

Developers will try to split it along technical Developers will try to split it along technical lineslines

Job seeker will fill out resume formJob seeker will fill out resume form Resume form will be submitted to databaseResume form will be submitted to database

Make sure to focus on business valueMake sure to focus on business value A job seeker can submit a resume that includes only A job seeker can submit a resume that includes only

basic information such as name, address, education basic information such as name, address, education history.history.

A job seeker can submit a resume that includes all A job seeker can submit a resume that includes all information an employer needs to see.information an employer needs to see.

This forces the developers to span the whole This forces the developers to span the whole architecture earlier on in a simpler mannerarchitecture earlier on in a simpler manner

Reduces riskReduces risk Focus on working software/shippable product!Focus on working software/shippable product!

Page 64: User Stories

Write closed storiesWrite closed stories

Have a clear goal being met with the Have a clear goal being met with the storystory BadBad

A recruiter can manage the ad she has placedA recruiter can manage the ad she has placed GoodGood

A recruiter can review resumes from applicants A recruiter can review resumes from applicants to one of her adsto one of her ads

A recruiter can change the recruiter date of an A recruiter can change the recruiter date of an adad

A recruiter can delete an application that is not A recruiter can delete an application that is not a good match for a joba good match for a job

Page 65: User Stories

Put constraints on cardsPut constraints on cards

Something that must be observed, Something that must be observed, not implemented.not implemented. The system must support peak usage of The system must support peak usage of

up to 50 concurrent usersup to 50 concurrent users Do not make it hard to internationalize Do not make it hard to internationalize

the software if needed laterthe software if needed later The new system must use our existing The new system must use our existing

order databaseorder database

Page 66: User Stories

Size stories to the Size stories to the horizonhorizon

A job seeker can post a resumeA job seeker can post a resume A job seeker can search job openingsA job seeker can search job openings A recruiter can post a job openingA recruiter can post a job opening A recruiter can search resumesA recruiter can search resumes

Focus on posting resumes first!Focus on posting resumes first! Add resume, edit resume, remove Add resume, edit resume, remove

resume, mark inactive, mark hidden, see resume, mark inactive, mark hidden, see how many views.how many views.

Page 67: User Stories

Keep the UI out as long as Keep the UI out as long as possiblepossible

Mixing requirements with solution Mixing requirements with solution specification!specification!

Page 68: User Stories

Some things aren’t Some things aren’t storiesstories

In a few cases, such as external In a few cases, such as external vendorvendor Screen mockScreen mock Use caseUse case UML DiagramUML Diagram SpecificationSpecification etcetc

Page 69: User Stories

Include user roles in Include user roles in storiesstories

as a (role) I want (function) because as a (role) I want (function) because (business value)(business value)

Page 70: User Stories

Write for one userWrite for one user

Job seeker can remove a resumeJob seeker can remove a resume Job seeker can remove her own Job seeker can remove her own

resumeresume

Page 71: User Stories

Write in active voiceWrite in active voice

BadBad A resume can be posted by a job seekerA resume can be posted by a job seeker

GoodGood A job seeker can post a resumeA job seeker can post a resume

Page 72: User Stories

Customer writesCustomer writes

Not developerNot developer But they can suggestBut they can suggest

Which maybe is write them then get signoffWhich maybe is write them then get signoff Offer adviceOffer advice

In the end the customer has to In the end the customer has to prioritize them so they need to know prioritize them so they need to know the language on the card fully.the language on the card fully.

Page 73: User Stories

Don’t number the cardsDon’t number the cards

Pointless over headPointless over head You’ll be shredding cards and You’ll be shredding cards and

creating cards oftencreating cards often

Page 74: User Stories

Don’t forget the purposeDon’t forget the purpose

Reminder about the requirements Reminder about the requirements not the document of the not the document of the requirements.requirements.

Don’t replace the conversation by Don’t replace the conversation by adding the detail.adding the detail.

Page 75: User Stories

Estimating and Estimating and PlanningPlanning

PART IIPART II

Page 76: User Stories

Estimating Estimating storiesstories

Chapter 8Chapter 8

Page 77: User Stories

Story pointsStory points

Relative to eachotherRelative to eachother Nebulous units of time (NUTs)Nebulous units of time (NUTs) Ideal daysIdeal days Easier than estimating time.Easier than estimating time.

How many centimeters are in this lineHow many centimeters are in this line How ‘big’ is this lineHow ‘big’ is this line Where is halfway on this lineWhere is halfway on this line Where is 1 quarter on this lineWhere is 1 quarter on this line

Page 78: User Stories

Estimate as a teamEstimate as a team

Who is ‘the team’Who is ‘the team’ Everyone who’s going to do the work.Everyone who’s going to do the work.

Collective ownershipCollective ownership Won’t know who will do the workWon’t know who will do the work

Less chance for sandbagging or low-Less chance for sandbagging or low-ballingballing

Customer does not interfere with Customer does not interfere with estimate, but can contribute**estimate, but can contribute**

Page 79: User Stories

EstimatingEstimating

Hear about the storyHear about the story Ask as many questions as needed to know Ask as many questions as needed to know

what is neededwhat is needed Write estimate on on cards or use existing Write estimate on on cards or use existing

cardscards All show estimateAll show estimate Talk about why the low and the highTalk about why the low and the high Re-bidRe-bid If the team cannot come to consensus then If the team cannot come to consensus then

“Do something”**“Do something”**

Page 80: User Stories

Everything takes 4 hoursEverything takes 4 hours

Keep in mind everything that has to Keep in mind everything that has to happen to complete the story.happen to complete the story. Unit testUnit test RefactoringRefactoring Talking to the customerTalking to the customer Enterprise specific “stuff”Enterprise specific “stuff” Code reviewCode review <Your organization/team/customers <Your organization/team/customers

definition of “DONE”>definition of “DONE”>

Page 81: User Stories

TriangulateTriangulate

Refer to other stories you’ve already Refer to other stories you’ve already estimated.estimated.

Page 82: User Stories

Using points as team Using points as team velocityvelocity

Check ‘yesterdays weather’Check ‘yesterdays weather’ Don’t take more than thatDon’t take more than that

Maybe stretch tasks**Maybe stretch tasks**

Page 83: User Stories

What if we’re pair What if we’re pair programming?programming?

Ideal pair daysIdeal pair days ““I feel” this is no different than I feel” this is no different than

“done”. If we’re suppose to pair “done”. If we’re suppose to pair program it’s assumed in our program it’s assumed in our estimate of done. (code review)estimate of done. (code review)

Page 84: User Stories

Precision decreases as size Precision decreases as size increasesincreases

½,1,2,3,5,8,13,20,40,80½,1,2,3,5,8,13,20,40,80 Don’t have to think about is it a 79 or Don’t have to think about is it a 79 or

8080

Page 85: User Stories

confusionsconfusions

Not equivalent to any other team’s Not equivalent to any other team’s pointspoints

Sum of smaller stories will not equal Sum of smaller stories will not equal the theme or epic they came fromthe theme or epic they came from

Sum of tasks will not be equal to the Sum of tasks will not be equal to the estimate of the initial story.estimate of the initial story.

Page 86: User Stories

Customer Customer responsibilitiesresponsibilities

Answer questionsAnswer questions Don’t estimateDon’t estimate Don’t urge lower/higher estimatesDon’t urge lower/higher estimates

Page 87: User Stories

Developer Developer responsibilitiesresponsibilities

Define story points in a manner that are Define story points in a manner that are relevant and sticking with that definitionrelevant and sticking with that definition

Give honest estimates. Don’t give into Give honest estimates. Don’t give into pressure to be lower. Don’t sandbag pressure to be lower. Don’t sandbag because it won’t help the situation it just because it won’t help the situation it just increases your velocity and sets you up increases your velocity and sets you up for failure later.for failure later.

Pair programming doesn’t affect points Pair programming doesn’t affect points only affects team velocity.only affects team velocity.

Page 88: User Stories

Planning a Planning a releaserelease

Chapter 9Chapter 9

Page 89: User Stories

When do we want to When do we want to release?release?

Setup the buckets to put stories in Setup the buckets to put stories in for a release and then put dates on for a release and then put dates on them.them. In scrumworks as you begin to burn In scrumworks as you begin to burn

down you’ll see how you faire with that down you’ll see how you faire with that date.date.

You can plan based on team velocity (if You can plan based on team velocity (if established)established) You can guess a team velocity.You can guess a team velocity.

Page 90: User Stories

What would you like it inWhat would you like it in

Must haveMust have Should haveShould have Could haveCould have Won’t have this timeWon’t have this time

Page 91: User Stories

Prioritizing storiesPrioritizing stories

But they’re all #1 priority! But they’re all #1 priority! The riskThe risk Impact to other storiesImpact to other stories Desirability to broad base of usersDesirability to broad base of users Desirability to small but important base of Desirability to small but important base of

users!users! Cohesiveness of a story to another story (not Cohesiveness of a story to another story (not

dependency, see INVEST)dependency, see INVEST) Developers will have a preference of Developers will have a preference of

implementation path. Customer wins these.implementation path. Customer wins these.

Page 92: User Stories

Cost Changes PriorityCost Changes Priority

Enter key to move between fields Enter key to move between fields because of DOS**because of DOS**

So: customer can choose and we So: customer can choose and we have to give them visibility into what have to give them visibility into what will happen with their choices.will happen with their choices.

Page 93: User Stories

Risky StoriesRisky Stories

Juicy bits first!Juicy bits first! Visibility into the risks.Visibility into the risks.

If you develop this story before this If you develop this story before this other story then there is “this” risk.other story then there is “this” risk.

Page 94: User Stories

Prioritizing Prioritizing InfrastructureInfrastructure

Be able to generate 50 stock images Be able to generate 50 stock images per second.per second.

If something like this is lower If something like this is lower priority talk about the infrastructure priority talk about the infrastructure need and how hard it is to refactor.need and how hard it is to refactor.

Page 95: User Stories

Iteration LengthIteration Length Avoid random changes to iteration lengthAvoid random changes to iteration length Longer = less over headLonger = less over head Shorter = less chance for development to go off Shorter = less chance for development to go off

the rails.the rails. No longer than a monthNo longer than a month No shorter than a week.No shorter than a week. Scrum = 30 daysScrum = 30 days XP = 1-2 weeksXP = 1-2 weeks It’s good to sync up with other teams in the It’s good to sync up with other teams in the

organization.organization. Evolve a culture that supports planning meetings, Evolve a culture that supports planning meetings,

stand-ups, and demo-daysstand-ups, and demo-days

Page 96: User Stories

From points to durationFrom points to duration

100 points100 points Iteration of 1 week was 10 pointsIteration of 1 week was 10 points 10 weeks10 weeks

Page 97: User Stories

Initial velocityInitial velocity

Do an initial iteration and use that as Do an initial iteration and use that as velocityvelocity Iteration 0Iteration 0

Use historical valuesUse historical values Take a guess!Take a guess!

Hopefully stories are small enough to Hopefully stories are small enough to guess how much time they’ll take.guess how much time they’ll take.

Page 98: User Stories

Creating the release planCreating the release plan

Pin to the wallPin to the wall SpreadsheetSpreadsheet Photocopied storiesPhotocopied stories Gannt chartsGannt charts

Iteration 1Iteration 1 Story 1Story 1 Story 2Story 2

Iteration 2Iteration 2 Story 3Story 3 Story 4Story 4

Page 99: User Stories

WarningWarning

Be careful of saying “we’ll be done Be careful of saying “we’ll be done June 4June 4thth””

Say we’ll be done in 7-9 iterations.Say we’ll be done in 7-9 iterations. Especially during first few releasesEspecially during first few releases Especially if the team composition Especially if the team composition

changes oftenchanges often

Page 100: User Stories

Developer Developer responsibilitiesresponsibilities

Provide info to prioritizeProvide info to prioritize RisksRisks InfrastructureInfrastructure

Create release plan based on Create release plan based on realistic estimatesrealistic estimates Appropriate project buffer (deployment Appropriate project buffer (deployment

concerns, etc)concerns, etc)

Page 101: User Stories

Customer Customer ResponsibilitiesResponsibilities

Prioritize stories into precise order you Prioritize stories into precise order you value them. value them. Not just stacks of high, medium, low.Not just stacks of high, medium, low.

Expressing honest deadlinesExpressing honest deadlines Don’t say June 15Don’t say June 15thth to be safe if august 15 to be safe if august 15thth is ok is ok

Understand difference between ideal time Understand difference between ideal time and calendar timeand calendar time

Split stories that contain components you Split stories that contain components you want to prioritize differently.want to prioritize differently.

Understand when a single developer has Understand when a single developer has less velocity than another.less velocity than another.

Page 102: User Stories

Planning an Planning an iterationiteration

Chapter 10Chapter 10

Page 103: User Stories

Iteration plan overviewIteration plan overview

Discuss a storyDiscuss a story Disaggregate the story into tasks Disaggregate the story into tasks

(decompose)(decompose) One developer accepts responsibility One developer accepts responsibility

for each taskfor each task Estimate the tasks, ensure they’re Estimate the tasks, ensure they’re

not overcommitted.not overcommitted.

Page 104: User Stories

Discuss the storyDiscuss the story Customer start with highest priority Customer start with highest priority

storystory Ask questions until they understand Ask questions until they understand

enough to break it into tasks (don’t need enough to break it into tasks (don’t need the complete detail of everything in the the complete detail of everything in the world!)world!) Not everyone needs the gross detailNot everyone needs the gross detail The dev can work with the customer to get The dev can work with the customer to get

the detail once they’re on the taskthe detail once they’re on the task Changing prioritiesChanging priorities

Implementations of database**Implementations of database**

Page 105: User Stories

Decompose to tasksDecompose to tasks No art, but stuff imagine this story: “A user No art, but stuff imagine this story: “A user

can search for a hotel on various fields”can search for a hotel on various fields” Code basic search screenCode basic search screen Code advanced search screenCode advanced search screen Code results screenCode results screen Write and tune SQL to query for basic searchesWrite and tune SQL to query for basic searches Write and tune sql to query for advanced Write and tune sql to query for advanced

searchessearches Document new functionality in help system and Document new functionality in help system and

users guideusers guide

Page 106: User Stories

GuidelinesGuidelines

If something is hard to estimate, don’t If something is hard to estimate, don’t have it in the story. Have it live without have it in the story. Have it live without a story. (scrumworks won’t support a story. (scrumworks won’t support this, so add a backlog item for ‘sprint 2 this, so add a backlog item for ‘sprint 2 homeless tasks’)homeless tasks’)

Separate tasks by developersSeparate tasks by developers If there’s need to know that a section of If there’s need to know that a section of

the story is done, break that out as a the story is done, break that out as a task (i.e. screen and some code behind)task (i.e. screen and some code behind)

Page 107: User Stories

Accepting ResponsibilityAccepting Responsibility

Write them up, someone accepts and Write them up, someone accepts and owns.owns.

Everyone’s responsibility to make Everyone’s responsibility to make sure the tasks gets done “we’re all in sure the tasks gets done “we’re all in this together”this together”

No one should say “well I finished No one should say “well I finished my work but Tom has tasks left”my work but Tom has tasks left”

Page 108: User Stories

Estimate and confirmEstimate and confirm

By this point tasks should be small By this point tasks should be small enough to be reliableenough to be reliable

If not, don’t worry, guess and move If not, don’t worry, guess and move on.on.

Add up the ideal hours and see if it’s Add up the ideal hours and see if it’s realistic.realistic. Let someone take somethingLet someone take something Hope for the bestHope for the best Drop a storyDrop a story

Page 109: User Stories

Developer Developer responsibilitiesresponsibilities

Participate in iteration planningParticipate in iteration planning Responsible for decomposing into tasks, Responsible for decomposing into tasks,

NOT just the stories you’re going to work on.NOT just the stories you’re going to work on. Accepting responsibility for tasks you will Accepting responsibility for tasks you will

work onwork on Ensuring you take the appropriate amount of Ensuring you take the appropriate amount of

workwork Monitoring the amount of work you have left Monitoring the amount of work you have left

and your teammates work. If you’re likely to and your teammates work. If you’re likely to finish early, help your teammate.finish early, help your teammate.

Page 110: User Stories

Customer Customer responsibilitiesresponsibilities

Prioritize storiesPrioritize stories Directing developers toward best Directing developers toward best

business value you can. If higher business value you can. If higher values have come to light since. values have come to light since. Adjust priority.Adjust priority.

Participate in iteration planning to Participate in iteration planning to field questions.field questions.

Page 111: User Stories

Measuring and monitoring Measuring and monitoring velocityvelocity

MeasuringMeasuring Planned vs actualPlanned vs actual Burndown chartsBurndown charts Hours remaining NOT expendedHours remaining NOT expended

MonitoringMonitoring Information Radiators**Information Radiators** Task boardTask board Burn boardBurn board Impediment BoardImpediment Board

Page 112: User Stories

Developer Developer responsibilitiesresponsibilities

Complete a story before moving onto Complete a story before moving onto the next.the next.

Understand impact any decision you Understand impact any decision you make on the velocity of the projectmake on the velocity of the project

Understand how to read the chartsUnderstand how to read the charts If manager/tracker understand when If manager/tracker understand when

to produce the charts and how.to produce the charts and how.

Page 113: User Stories

Customer Customer ResponsibilitiesResponsibilities

Understand how to read and interpret Understand how to read and interpret the charts shown in this chapterthe charts shown in this chapter

Know the velocity of the teamKnow the velocity of the team Know the actual velocity and how it Know the actual velocity and how it

compares to planned velocity and compares to planned velocity and whether to correct.whether to correct.

Add or remove stories from the Add or remove stories from the release to ensure objectives are met.release to ensure objectives are met.

Page 114: User Stories

Part IIIPart III

FAQFAQ

Page 115: User Stories

Stories aren’t IEEE830Stories aren’t IEEE830

The system shallThe system shall The system shallThe system shall The system shallThe system shall The system shallThe system shall

Focus on the user and interactions!Focus on the user and interactions!

Page 116: User Stories

Stories aren’t use casesStories aren’t use cases

Use case is generally larger scopeUse case is generally larger scope Stories differ in level of Stories differ in level of

completeness.completeness. A use case has the tests before it’s A use case has the tests before it’s

finishedfinished A story delays the acceptance until the A story delays the acceptance until the

last possible moment before last possible moment before implementation saving time.implementation saving time.

Page 117: User Stories

Stories aren’t scenariosStories aren’t scenarios ScenarioScenario

SettingSetting ActorsActors Goals/objectivesGoals/objectives Actions/eventsActions/events

StoryStory A roleA role An objective/goalAn objective/goal A valueA value C C C (card conversation complete)C C C (card conversation complete)

Page 118: User Stories

Why use?Why use? Emphasize verbal communicationEmphasize verbal communication Comprehensible by everyoneComprehensible by everyone Right size for planningRight size for planning Work for IIDWork for IID Encourage deferring detail (less waste)Encourage deferring detail (less waste) Support opportunistic designSupport opportunistic design

Know it when I see it!Know it when I see it! Participatory designParticipatory design Build tacit knowledge (explicit, tacit, Build tacit knowledge (explicit, tacit,

externalize, combine, internalize)externalize, combine, internalize) Face it, who really reads the requirements? Face it, who really reads the requirements?

Page 119: User Stories

Developer Developer responsibilitiesresponsibilities

Understand why we choose a Understand why we choose a techniquetechnique

Understand advantages of other Understand advantages of other requirements techniques and when requirements techniques and when to apply them.to apply them. Use caseUse case DiagramsDiagrams Uml modelsUml models Domain modelsDomain models

Page 120: User Stories

Catalog of story smellsCatalog of story smells Too smallToo small

Need to revise estimatesNeed to revise estimates InterdependentInterdependent

Hard to plan because of dependenciesHard to plan because of dependencies Gold-platingGold-plating

Adding unplanned features or interpreting storiesAdding unplanned features or interpreting stories Too many detailsToo many details

Too much time spent on gathering befor eimplementing Something!Too much time spent on gathering befor eimplementing Something! Including UI too soonIncluding UI too soon

Details about specific ui things (dropdowns, tabs)Details about specific ui things (dropdowns, tabs) Thinking too far aheadThinking too far ahead

Hard to fit on cardsHard to fit on cards Splitting too many stories during planning to ‘fit’Splitting too many stories during planning to ‘fit’ Trouble prioritizingTrouble prioritizing

Missing biz value?Missing biz value? Too big?Too big? A little of this and of that?A little of this and of that?

Customer won’t write/prioritizeCustomer won’t write/prioritize Let them off the hook somehowLet them off the hook somehow

Page 121: User Stories

Using stories with ScrumUsing stories with Scrum 30 day iteration30 day iteration Scrum teamScrum team

4-74-7 Cross functional (dev, test, business, other)Cross functional (dev, test, business, other)

Product Backlog (uncommitted)Product Backlog (uncommitted) List of stories prioritized and estimatedList of stories prioritized and estimated

Sprint planningSprint planning Select top priority subset and COMMITSelect top priority subset and COMMIT

Sprint ReviewSprint Review Show off the completed functionalityShow off the completed functionality Define DONE firstDefine DONE first Review completed stories for completenessReview completed stories for completeness Review uncompleted stories to verify they’re NOT in the demoReview uncompleted stories to verify they’re NOT in the demo

Daily Scrum (standup)Daily Scrum (standup) What did you do since last scrum?What did you do since last scrum? What are you working on after this scrum?What are you working on after this scrum? What’s in your way?What’s in your way?

Page 122: User Stories

Additional topicsAdditional topics

Paper or software?Paper or software? Stories and interface?Stories and interface?

If important make a UI constraintIf important make a UI constraint Write two Write two

Retaining storiesRetaining stories Stories for bugsStories for bugs Colored cards?Colored cards?