The document discusses planning and estimating user stories for software development. It provides guidance on writing user stories, estimating story points, determining team velocity, prioritizing stories, and planning iterations and releases. Key points include writing stories from the user's perspective using active voice, estimating stories as a team in story points rather than hours, using velocity from past iterations to plan future work, and prioritizing stories based on business value and risk.

1. User Stories James Peckham (Extracted from Mike Cohn’s Book “User Stories Applied”)

2. Customer Team (Acceptance) Testers Product manager Real users Interaction designers

3. Developer DBA Technical Writer (Documentation) Programmer Build master/wrangler

4. What is a user story? Card Conversation Confirmation

5. Where are the details? One thing to say, another to code and test… I want to post jobs Additional stories? Confirmation through tests!

6. What do I write Theme I want a Job board Epic Story

7. Epic A user can search for a job A company can post job openings

8. Story A user can search for jobs by attributes like location, salary range, job title, company name, and the date the job was posted A user can view information about each job that is matched by a search A user can view detailed information about a company that has posted a job

9. What do I Write? Don’t have to go this far A user can view a job description A user can view jobs salary range A user can view the location of a job Don’t have to do requirements style 4.6)A user can view information about each job that is matched by a search 4.6.1) a user can view the job description 4.6.2) a user can view a job’s salary range. 4.6.3) a user can view the location of a job

10. What is the process like? Not like waterfall User/Proxy can’t just say what the stories are then go away. Users/Proxy should Play active role in writing stories Why wouldn’t you want to be involved with writing the stories? Written in language of the business instead of tech jargon. (this will help with prioritization and choosing of stories for planning releases)

11. How long does it have to be? On the back of the card a reminder for tests Try with empty job description Try with a really long job description Try with missing salary Try with six digit salary

12. When do we write them? Story writing workshop During demo Any time you want! Get business language! (easy to read, no technical jargon!)

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

14. What are acceptance tests? Write tests early as possible Communicate earlier such as A user can pay for the items in her shopping cart with a credit card Test with visa, MC, Amex (pass). Test with diners club (fail) Test with visa debit card (pass) Test with good, bad and missing ID numbers from back of card Test with expired cards Test with different purchase amounts (including over limit)

15. Why? Emphasize verbal rather than written communication (proven better!) User stories comprehensible by both users and developers Right size for planning and estimating Work for iterative and incremental development Encourage deferring the detail until you have the best understanding of what you really need.

16. Writing Stories Chapter 2

17. INVEST Independent Negotiable Valuable to users or customers Estimable Small Testable

18. Independent Care taken to introduce as little dependencies as possible. BAD Company can pay for a job posting with a visa card Company can pay for a job posting with a master card Company can pay for a job posting with an American Express Good Company can pay for a job posting with a credit card Also good Company can pay for a job posting with one type of a credit card Company can pay for a job posting with two additional types of credit cards Last resort Two estimates on the card i.e. 8/3

19. Negotiable Not contracts Tough to include Just enough detail Putting note at the bottom of card, but leaving it open to be negotiable. Mistake extra detail as extra precision and forget the conversation. A phrase to remind for conversation A note or two to remind for any further negotiation/issues.

20. Valuable to purchasers or users Throughout the development process, the development team will produce documentation suitable for an ISO 9001 audit. -- purchaser Not All connections to the database are through a connection pool All error handling and logging is done through a set of common classes. If there’s a technical story put it in terms the business can understand Up to fifty users should be able to use the application with a five-user database license All errors are presented to the user and logged in a consistent manner.

21. Estimable Common reasons why they’re not Lack domain knowledge Can discuss with business people and learn Lack technical knowledge Can spike on the story to learn more about it Two stories, one for the spike one for the real work Story is too big Sometimes useful to write the epic to be a placeholder for some glossed over part of a system. Pulled from thin air estimate! Or break it down.

22. Small Size does matter A user can plan a vacation (EPIC) Based on team and capabilities and technology in use. Compound or complex Epic stories. Too much for a slide… page 24

23. Testable User must find the software easy to use. A novice user is able to complete common workflows without training A user must not have to wait long for a screen to appear. New screens appear within two seconds in 95% of all cases. Strive for 99% automation Automate on the code not just the UI. Fit is good NUnit is good

24. User role Modeling Chapter 3

25. User Roles Examples Job Seeker Employer Administrator Helpdesk agent

26. steps Brainstorm initial set Organize set Consolidate the roles Refine the roles

27. Brainstorming roles Before any project (before any theme of stories) Grab stack of cards Timebox Write as many names of people and their role in using the software. 15min or less usually.

28. Organize cards Find the description of a higher grouping and start filtering into those groups all the cards. Arrange on a table.

29. Consolidate roles Read any that sound similar. If it’s redundant find a common name and remove the extras. If there’s no reason to distinguish, remove.

30. Refine roles Attributes worth considering in distinguishing from one role to another Frequency with which the user will use software Users level of expertise with the domain Users general level of proficiency with computers and software Users level of proficiency with the software being developed General goal for using the software Rich experience, Convenience

31. optional techniques for roles Personas Mario works as a recruiter in the personnel department of speedy networks, a manufacturer of high end …. etc Extreme characters Consider a PDA for: BMW driving management consultant The pope Drug dealer

32. Gathering stories chapter4

33. Trawling Big wide net, get all the big fish. Then start casting smaller nets. Why isn’t little enough? Prescriptive process feel… Can evolve from the epic to more stories later on!

34. techniques User interviews Questionnaires Observation Story-writing workshops

35. interviews Real users when possible You build what I asked for but that’s not what I want! Just because they have the knowledge doesn’t mean they know the way to implement Complex mini-language lesson-  visual designer instead.

36. Open ended and context free questions Would you like that app to be in a browser? Would you like our new app in a browser rather than a native windows application even if it means reduced performance, poorer overall user experience, and less interactivity? How fast do searches need to be? What performance is required? Is performance more important in some parts of the application?

37. Questionnaires Gather info on stories from bigger user base Large number of answers for a specific question Bad “What features would you like to see” Miss things if you give them a multiple choice Hard to tabulate if open text

38. Story Writing Workshops Who Developers Users Product customer Other stakeholders Low fidelity prototyping whiteboard, Note cards Paper Component layout Throw away the low-fidelity prototype! Access competitive products if you’re stuck!

39. Developer responsibilities Understand and use multiple techniques while trawling Make best use of open ended and context free questions

40. Customer responsibilities Understand and use multiple techniques while trawling for stories Writing as many stories as early as possible Main representative of the software and responsible for options in communicating with them If you need or want help responsible for scheduling and running story writing workshops Responsible for making sure all roles are appropriately represented

41. Working with user proxies Chapter 5

42. Selecting user proxies It’s difficult to get all the right real users But important to try! Can’t get our user because of their manager (a helpdesk, NOC, etc) Bring manager in Corroborate Development manager = worst proxy possible!  Sales Person = bad proxy but great way to get introduced to good users.

43. Domain experts Great domain modelers Can put definitions to unique domain language Identify business rules Real user better For interactions with the software

44. Marketing group Focus on quantity of features rather than the quality of those features Might not have insight to provide detail about those stories*

45. Former Users Experience will expire!

46. Customers Buyers not necessarily users!

47. Trainers and tech support Ease of training Ease of supporting Good goals, but what’s important?

48. Business or System analyst One foot in tech one foot in the domain. Tendency to be forced into thinking the problem out instead of getting the information from the users. 3 weeks to figure out a story instead of a 2 hour session.*

49. What to do when working with proxy When users exist but access is limited User task force story writers under a proxy When there is no user available Use more than one Competing products Reviews of their products Can you do it yourself? Avoid it! Developers won’t have the ‘closeness’ with user-base Even if Developers are the users! Especially if the Developers are the users! Cherry pick! Constituting the Customer team Put real users on the customer team!

50. Dev responsibilities Organize and select appropriate customer Understand how different user proxies can affect the system being built and influence the interactions.

51. Customer Responsibilities If you’re not the user, know the proxy type that describes you! Understand what biases you may bring to the table and work towards overcoming them.

52. Acceptance Testing User Stories Chapter 6

53. Write tests before coding When? Capture specific details when talking At the start of the iteration before programming begins When new tests are discovered after the programming of a story Considerations What else would a programmer need? What am I assuming? Are there circumstances where this story will be different? What could go wrong?

54. Customer Team Specifies tests Because it’s their vision! They can work with a programmer to create the tests. Testers can augment the tests of course to better suite the need.

55. Testing is part of the process Not something you do “At the end” Testers can’t learn of the system from the programmers. In the process Write a test Write code to support the test Think of more tests.

56. How many are too many? Continue to write as long as they add value or clarity to the story. Good programming teams will have Unit Tests in place that handle low level things. i.e. feb 30 th not a real date

57. Framework Integrated Test Spreadsheet/data table tests Action tests Requires test harness development (a programmer) Requires decoupling from User interface Fitnesse Wiki based execution of FIT tests

58. Types of tests Mike Cohn’s ‘reason’ list User interface tests Usability testing Performance testing Stress Testing Crystal Clear ‘how’ List GUI based acceptance (Expensive and slow) GUI-less acceptance Unit Tests

59. Developer responsibilities Automating Thinking of additional tests Unit testing code so acceptance tests don’t need specified for low hanging fruit

60. Customer Team Responsibilities Responsible for acceptance tests Responsible for executing tests

61. Guidelines for good stories Chapter 7

62. Start with goal stories Search for jobs Automate search process so she doesn’t have to search manually each time Make her resume available so that companies may search for her Easily apply for any jobs she likes

63. Slice the cake When there’s a large story Developers will try to split it along technical lines Job seeker will fill out resume form Resume form will be submitted to database Make sure to focus on business value A job seeker can submit a resume that includes only basic information such as name, address, education history. A job seeker can submit a resume that includes all information an employer needs to see. This forces the developers to span the whole architecture earlier on in a simpler manner Reduces risk Focus on working software/shippable product!

64. Write closed stories Have a clear goal being met with the story Bad A recruiter can manage the ad she has placed Good A recruiter can review resumes from applicants to one of her ads A recruiter can change the recruiter date of an ad A recruiter can delete an application that is not a good match for a job

65. Put constraints on cards Something that must be observed, not implemented. The system must support peak usage of up to 50 concurrent users Do not make it hard to internationalize the software if needed later The new system must use our existing order database

66. Size stories to the horizon A job seeker can post a resume A job seeker can search job openings A recruiter can post a job opening A recruiter can search resumes Focus on posting resumes first! Add resume, edit resume, remove resume, mark inactive, mark hidden, see how many views.

67. Keep the UI out as long as possible Mixing requirements with solution specification!

68. Some things aren’t stories In a few cases, such as external vendor Screen mock Use case UML Diagram Specification etc

69. Include user roles in stories as a (role) I want (function) because (business value)

70. Write for one user Job seeker can remove a resume Job seeker can remove her own resume

71. Write in active voice Bad A resume can be posted by a job seeker Good A job seeker can post a resume

72. Customer writes Not developer But they can suggest Which maybe is write them then get signoff Offer advice In the end the customer has to prioritize them so they need to know the language on the card fully.

73. Don’t number the cards Pointless over head You’ll be shredding cards and creating cards often

74. Don’t forget the purpose Reminder about the requirements not the document of the requirements. Don’t replace the conversation by adding the detail.

75. Estimating and Planning PART II

76. Estimating stories Chapter 8

77. Story points Relative to eachother Nebulous units of time (NUTs) Ideal days Easier than estimating time. How many centimeters are in this line How ‘big’ is this line Where is halfway on this line Where is 1 quarter on this line

78. Estimate as a team Who is ‘the team’ Everyone who’s going to do the work. Collective ownership Won’t know who will do the work Less chance for sandbagging or low-balling Customer does not interfere with estimate, but can contribute**

79. Estimating Hear about the story Ask as many questions as needed to know what is needed Write estimate on on cards or use existing cards All show estimate Talk about why the low and the high Re-bid If the team cannot come to consensus then “Do something”**

80. Everything takes 4 hours Keep in mind everything that has to happen to complete the story. Unit test Refactoring Talking to the customer Enterprise specific “stuff” Code review <Your organization/team/customers definition of “DONE”>

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

82. Using points as team velocity Check ‘yesterdays weather’ Don’t take more than that Maybe stretch tasks**

83. What if we’re pair programming? Ideal pair days “I feel” this is no different than “done”. If we’re suppose to pair program it’s assumed in our estimate of done. (code review)

84. Precision decreases as size increases ½,1,2,3,5,8,13,20,40,80 Don’t have to think about is it a 79 or 80

85. confusions Not equivalent to any other team’s points Sum of smaller stories will not equal the theme or epic they came from Sum of tasks will not be equal to the estimate of the initial story.

86. Customer responsibillities Answer questions Don’t estimate Don’t urge lower/higher estimates

87. Developer responsibilities Define story points in a manner that are relavent and sticking with that definition Give honest estimates. Don’t give into pressure to be lower. Don’t sandbag because it won’t help the situation it just increases your velocity and sets you up for failure later. Pair programming doesn’t affect points only affects team velocity.

88. Planning a release Chapter 9

89. When do we want to release? Setup the buckets to put stories in for a release and then put dates on them. In scrumworks as you begin to burn down you’ll see how you faire with that date. You can plan based on team velocity (if established) You can guess a team velocity.

90. What would you like it in Must have Should have Could have Won’t have this time

91. Prioritizing stories But they’re all #1 priority!  The risk Impact to other stories Desirability to broad base of users Desirability to small but important base of users! Cohesiveness of a story to another story (not dependency, see INVEST) Developers will have a preference of implementation path. Customer wins these.

92. Cost Changes Priority Enter key to move between fields because of DOS** So: customer can choose and we have to give them visibility into what will happen with their choices.

93. Risky Stories Juicy bits first! Visibility into the risks. If you develop this story before this other story then there is “this” risk.

94. Prioritizing Infrastructure Be able to generate 50 stock images per second. If something like this is lower priority talk about the infrastructure need and how hard it is to refactor.

95. Iteration Length Avoid random changes to iteration length Longer = less over head Shorter = less chance for development to go off the rails. No longer than a month No shorter than a week. Scrum = 30 days XP = 1-2 weeks It’s good to sync up with other teams in the organization. Evolve a culture that supports planning meetings, standups, and demo-days

96. From points to duration 100 points Iteration of 1 week was 10 pnts 10 weeks

97. Initial velocity Do an initial iteration and use that as velocity Iteration 0 Use historical values Take a guess! Hopefully stories are small enough to guess how much time they’ll take.

98. Creating the release plan Pin to the wall Spreadsheet Photocopied stories Gannt charts Iteration 1 Story 1 Story 2 Iteration 2 Story 3 Story 4

99. Warning Be careful of saying “we’ll be done june 4 th ” Say we’ll be done in 7-9 iterations. Especially during first few releases Especially if the team composition changes alot

100. Developer responsibilities Provide info to prioritize Risks Infrastructure Create release plan based on realistic estimates Appropriate project buffer (deployment concerns, etc)

101. Customer Responsibilities Prioritize stories into precise order you value them. Not just stacks of high, medium, low. Expressing honest deadlines Don’t say june 15 th to be safe if august 15 th is ok Understand difference between ideal time and calendar time Split stories that contain components you want to prioritize differently. Understand when a single developer has less velocity than another.

102. Planning an iteration Chapter 10

103. Iteration plan overview Discuss a story Disaggregate the story into tasks (decompose) One developer accepts responsibility for each task Estimate the tasks, ensure they’re not overcommitted.

104. Discuss the story Customer start with highest priority story Ask questions until they understand enough to break it into tasks (don’t need the complete detail of everything in the world!) Not everyone needs the gross detail The dev can work with the customer to get the detail once they’re on the task Changing priorities Implementations of database**

105. Decompose to tasks No art, but stuff imagine this story: “A user can search for a hotel on various fields” Code basic search screen Code advanced search screen Code results screen Write and tune sql to query for basic searches Write and tune sql to query for advanced searches Document new functionality in help system and users guide

106. Guidelines If something is hard to estimate, don’t have it in the story. Have it live without a story. (scrumworks won’t support this, so add a backlog item for ‘sprint 2 homeless tasks’) Separate tasks by developers If there’s need to know that a section of the story is done, break that out as a task (i.e. screen and some code behind)

107. Accepting Responsibility Write them up, someone accepts and owns. Everyone’s responsibility to make sure the tasks gets done “we’re all in this together” No one should say “well I finished my work but Tom has tasks left”

108. Estimate and confirm By this point tasks should be small enough to be reliable If not, don’t worry, guess and move on. Add up the ideal hours and see if it’s realistic. Let someone take something Hope for the best Drop a story

109. Developer responsibilities Participate in iteration planning Responsible for decomposing into tasks, NOT just the stories you’re going to work on. Accepting responsibility for tasks you will work on Ensuring you take the appropriate amount of work Monitoring the amount of work you have left and your teammates work. If you’re likely to finish early, help your teammate.

110. Customer responsibilities Prioritize stories Directing developers toward best business value you can. If higher values have come to light since. Adjust priority. Participate in iteration planning to field questions.

111. Measuring and monitoring velocity Measuring Planned vs actual Burndown charts Hours remaining NOT expended Monitoring Information Radiators** Task board Burn board Impediment Board

112. Developer responsibilities Complete a story before moving onto the next. Understand impact any decision you make on the velocity of the project Understand how to read the charts If manager/tracker understand when to produce the charts and how.

113. Customer Responsibilities Understand how to read and interpret the charts shown in this chapter Know the velocity of the team Know the actual velocity and how it compares to planned velocity and whether to correct. Add or remove stories from the release to ensure objectives are met.

114. Part III FAQ

115. Stories aren’t IEEE830 The system shall The system shall The system shall The system shall Focus on the user and interactions!

116. Stories aren’t use cases Use case is generally larger scope Stories differ in level of completeness. A use case has the tests before it’s finished A story delays the acceptance until the last possible moment before implementation saving time.

117. Stories aren’t scenarios Scenario Setting Actors Goals/objectives Actions/events Story A role An objective/goal A value C C C (card conversation complete)

118. Why use? Emphasize verbal communication Comprehensible by everyone Right size for planning Work for IID Encourage deferring detail (less waste) Support opportunistic design Know it when I see it! Participatory design Build tacit knowledge (explicit, tacit, externalize, combine, internalize) Face it, who really reads the requirements? 

119. Developer responsibilities Understand why we choose a technique Understand advantages of other requirements techniques and when to apply them. Use case Diagrams Uml models Domain models

120. Catalog of story smells Too small Need to revise estimates Interdependent Hard to plan because of dependencies Goldplating Adding unplanned features or interpreting stories Too many details Too much time spent on gathering befor eimplementing Something! Including UI too soon Details about specific ui things (dropdowns, tabs) Thinking too far ahead Hard to fit on cards Splitting too many stories during planning to ‘fit’ Trouble prioritizing Missing biz value? Too big? A little of this and of that? Customer won’t write/prioritize Let them off the hook somehow

121. Using stories with Scrum 30 day iteration Scrum team 4-7 Cross functional (dev, test, business, other) Product Backlog (uncommitted) List of stories prioritized and estimated Sprint planning Select top priority subset and COMMIT Sprint Review Show off the completed functionality Define DONE first Review completed stories for completeness Review uncompleted stories to verify they’re NOT in the demo Daily Scrum (standup) What did you do since last scrum? What are you working on after this scrum? What’s in your way?

122. Additional topics Paper or software? Stories and interface? If important make a UI constraint Write two  Retaining stories Stories for bugs Colored cards?