User Stories

2,026 views

Published on

0 Comments
2 Likes
Statistics
Notes
  • Be the first to comment

No Downloads
Views
Total views
2,026
On SlideShare
0
From Embeds
0
Number of Embeds
3
Actions
Shares
0
Downloads
138
Comments
0
Likes
2
Embeds 0
No embeds

No notes for slide
  • User Stories

    1. 1. User Stories James Peckham (Extracted from Mike Cohn’s Book “User Stories Applied”)
    2. 2. Customer Team <ul><li>(Acceptance) Testers </li></ul><ul><li>Product manager </li></ul><ul><li>Real users </li></ul><ul><li>Interaction designers </li></ul>
    3. 3. Developer <ul><li>DBA </li></ul><ul><li>Technical Writer (Documentation) </li></ul><ul><li>Programmer </li></ul><ul><li>Build master/wrangler </li></ul>
    4. 4. What is a user story? <ul><li>Card </li></ul><ul><li>Conversation </li></ul><ul><li>Confirmation </li></ul>
    5. 5. Where are the details? <ul><li>One thing to say, another to code and test… </li></ul><ul><ul><li>I want to post jobs </li></ul></ul><ul><li>Additional stories? </li></ul><ul><li>Confirmation through tests! </li></ul>
    6. 6. What do I write <ul><li>Theme </li></ul><ul><ul><li>I want a Job board </li></ul></ul><ul><li>Epic </li></ul><ul><li>Story </li></ul>
    7. 7. Epic <ul><ul><li>A user can search for a job </li></ul></ul><ul><ul><li>A company can post job openings </li></ul></ul>
    8. 8. Story <ul><ul><li>A user can search for jobs by attributes like location, salary range, job title, company name, and the date the job was posted </li></ul></ul><ul><ul><li>A user can view information about each job that is matched by a search </li></ul></ul><ul><ul><li>A user can view detailed information about a company that has posted a job </li></ul></ul>
    9. 9. What do I Write? <ul><li>Don’t have to go this far </li></ul><ul><ul><li>A user can view a job description </li></ul></ul><ul><ul><li>A user can view jobs salary range </li></ul></ul><ul><ul><li>A user can view the location of a job </li></ul></ul><ul><li>Don’t have to do requirements style </li></ul><ul><ul><li>4.6)A user can view information about each job that is matched by a search </li></ul></ul><ul><ul><ul><li>4.6.1) a user can view the job description </li></ul></ul></ul><ul><ul><ul><li>4.6.2) a user can view a job’s salary range. </li></ul></ul></ul><ul><ul><ul><li>4.6.3) a user can view the location of a job </li></ul></ul></ul>
    10. 10. What is the process like? <ul><li>Not like waterfall </li></ul><ul><ul><li>User/Proxy can’t just say what the stories are then go away. </li></ul></ul><ul><ul><li>Users/Proxy should Play active role in writing stories </li></ul></ul><ul><ul><ul><li>Why wouldn’t you want to be involved with writing the stories? </li></ul></ul></ul><ul><ul><ul><li>Written in language of the business instead of tech jargon. (this will help with prioritization and choosing of stories for planning releases) </li></ul></ul></ul>
    11. 11. How long does it have to be? <ul><li>On the back of the card a reminder for tests </li></ul><ul><ul><li>Try with empty job description </li></ul></ul><ul><ul><li>Try with a really long job description </li></ul></ul><ul><ul><li>Try with missing salary </li></ul></ul><ul><ul><li>Try with six digit salary </li></ul></ul>
    12. 12. When do we write them? <ul><li>Story writing workshop </li></ul><ul><li>During demo </li></ul><ul><li>Any time you want! </li></ul><ul><ul><li>Get business language! (easy to read, no technical jargon!) </li></ul></ul>
    13. 13. Planning releases <ul><li>Guess velocity for first iteration! </li></ul><ul><li>Choose iteration length 1-4 weeks </li></ul><ul><li>Arrange stories into releases. </li></ul>
    14. 14. What are acceptance tests? <ul><li>Write tests early as possible </li></ul><ul><li>Communicate earlier such as </li></ul><ul><ul><li>A user can pay for the items in her shopping cart with a credit card </li></ul></ul><ul><ul><ul><li>Test with visa, MC, Amex (pass). </li></ul></ul></ul><ul><ul><ul><li>Test with diners club (fail) </li></ul></ul></ul><ul><ul><ul><li>Test with visa debit card (pass) </li></ul></ul></ul><ul><ul><ul><li>Test with good, bad and missing ID numbers from back of card </li></ul></ul></ul><ul><ul><ul><li>Test with expired cards </li></ul></ul></ul><ul><ul><ul><li>Test with different purchase amounts (including over limit) </li></ul></ul></ul>
    15. 15. Why? <ul><li>Emphasize verbal rather than written communication (proven better!) </li></ul><ul><li>User stories comprehensible by both users and developers </li></ul><ul><li>Right size for planning and estimating </li></ul><ul><li>Work for iterative and incremental development </li></ul><ul><li>Encourage deferring the detail until you have the best understanding of what you really need. </li></ul>
    16. 16. Writing Stories Chapter 2
    17. 17. INVEST <ul><li>Independent </li></ul><ul><li>Negotiable </li></ul><ul><li>Valuable to users or customers </li></ul><ul><li>Estimable </li></ul><ul><li>Small </li></ul><ul><li>Testable </li></ul>
    18. 18. Independent <ul><li>Care taken to introduce as little dependencies as possible. </li></ul><ul><li>BAD </li></ul><ul><ul><li>Company can pay for a job posting with a visa card </li></ul></ul><ul><ul><li>Company can pay for a job posting with a master card </li></ul></ul><ul><ul><li>Company can pay for a job posting with an American Express </li></ul></ul><ul><li>Good </li></ul><ul><ul><li>Company can pay for a job posting with a credit card </li></ul></ul><ul><li>Also good </li></ul><ul><ul><li>Company can pay for a job posting with one type of a credit card </li></ul></ul><ul><ul><li>Company can pay for a job posting with two additional types of credit cards </li></ul></ul><ul><li>Last resort </li></ul><ul><ul><li>Two estimates on the card i.e. 8/3 </li></ul></ul>
    19. 19. Negotiable <ul><li>Not contracts </li></ul><ul><li>Tough to include Just enough detail </li></ul><ul><li>Putting note at the bottom of card, but leaving it open to be negotiable. </li></ul><ul><li>Mistake extra detail as extra precision and forget the conversation. </li></ul><ul><li>A phrase to remind for conversation </li></ul><ul><li>A note or two to remind for any further negotiation/issues. </li></ul>
    20. 20. Valuable to purchasers or users <ul><li>Throughout the development process, the development team will produce documentation suitable for an ISO 9001 audit. -- purchaser </li></ul><ul><li>Not </li></ul><ul><ul><li>All connections to the database are through a connection pool </li></ul></ul><ul><ul><li>All error handling and logging is done through a set of common classes. </li></ul></ul><ul><li>If there’s a technical story put it in terms the business can understand </li></ul><ul><ul><li>Up to fifty users should be able to use the application with a five-user database license </li></ul></ul><ul><ul><li>All errors are presented to the user and logged in a consistent manner. </li></ul></ul>
    21. 21. Estimable <ul><li>Common reasons why they’re not </li></ul><ul><ul><li>Lack domain knowledge </li></ul></ul><ul><ul><ul><li>Can discuss with business people and learn </li></ul></ul></ul><ul><ul><li>Lack technical knowledge </li></ul></ul><ul><ul><ul><li>Can spike on the story to learn more about it </li></ul></ul></ul><ul><ul><ul><ul><li>Two stories, one for the spike one for the real work </li></ul></ul></ul></ul><ul><ul><li>Story is too big </li></ul></ul><ul><ul><ul><li>Sometimes useful to write the epic to be a placeholder for some glossed over part of a system. </li></ul></ul></ul><ul><ul><ul><ul><li>Pulled from thin air estimate! </li></ul></ul></ul></ul><ul><ul><ul><li>Or break it down. </li></ul></ul></ul>
    22. 22. Small <ul><li>Size does matter </li></ul><ul><ul><li>A user can plan a vacation (EPIC) </li></ul></ul><ul><li>Based on team and capabilities and technology in use. </li></ul><ul><li>Compound or complex Epic stories. </li></ul><ul><li>Too much for a slide… page 24 </li></ul>
    23. 23. Testable <ul><li>User must find the software easy to use. </li></ul><ul><ul><li>A novice user is able to complete common workflows without training </li></ul></ul><ul><li>A user must not have to wait long for a screen to appear. </li></ul><ul><ul><li>New screens appear within two seconds in 95% of all cases. </li></ul></ul><ul><li>Strive for 99% automation </li></ul><ul><li>Automate on the code not just the UI. </li></ul><ul><ul><li>Fit is good </li></ul></ul><ul><ul><li>NUnit is good </li></ul></ul>
    24. 24. User role Modeling Chapter 3
    25. 25. User Roles <ul><li>Examples </li></ul><ul><ul><li>Job Seeker </li></ul></ul><ul><ul><li>Employer </li></ul></ul><ul><ul><li>Administrator </li></ul></ul><ul><ul><li>Helpdesk agent </li></ul></ul>
    26. 26. steps <ul><li>Brainstorm initial set </li></ul><ul><li>Organize set </li></ul><ul><li>Consolidate the roles </li></ul><ul><li>Refine the roles </li></ul>
    27. 27. Brainstorming roles <ul><li>Before any project (before any theme of stories) </li></ul><ul><li>Grab stack of cards </li></ul><ul><li>Timebox </li></ul><ul><li>Write as many names of people and their role in using the software. </li></ul><ul><li>15min or less usually. </li></ul>
    28. 28. Organize cards <ul><li>Find the description of a higher grouping and start filtering into those groups all the cards. </li></ul><ul><li>Arrange on a table. </li></ul>
    29. 29. Consolidate roles <ul><li>Read any that sound similar. If it’s redundant find a common name and remove the extras. </li></ul><ul><li>If there’s no reason to distinguish, remove. </li></ul>
    30. 30. Refine roles <ul><li>Attributes worth considering in distinguishing from one role to another </li></ul><ul><ul><li>Frequency with which the user will use software </li></ul></ul><ul><ul><li>Users level of expertise with the domain </li></ul></ul><ul><ul><li>Users general level of proficiency with computers and software </li></ul></ul><ul><ul><li>Users level of proficiency with the software being developed </li></ul></ul><ul><ul><li>General goal for using the software </li></ul></ul><ul><ul><ul><li>Rich experience, </li></ul></ul></ul><ul><ul><ul><li>Convenience </li></ul></ul></ul>
    31. 31. optional techniques for roles <ul><li>Personas </li></ul><ul><ul><li>Mario works as a recruiter in the personnel department of speedy networks, a manufacturer of high end …. etc </li></ul></ul><ul><li>Extreme characters </li></ul><ul><ul><li>Consider a PDA for: </li></ul></ul><ul><ul><ul><li>BMW driving management consultant </li></ul></ul></ul><ul><ul><ul><li>The pope </li></ul></ul></ul><ul><ul><ul><li>Drug dealer </li></ul></ul></ul>
    32. 32. Gathering stories chapter4
    33. 33. Trawling <ul><li>Big wide net, get all the big fish. </li></ul><ul><li>Then start casting smaller nets. </li></ul><ul><li>Why isn’t little enough? </li></ul><ul><ul><li>Prescriptive process feel… </li></ul></ul><ul><ul><li>Can evolve from the epic to more stories later on! </li></ul></ul>
    34. 34. techniques <ul><li>User interviews </li></ul><ul><li>Questionnaires </li></ul><ul><li>Observation </li></ul><ul><li>Story-writing workshops </li></ul>
    35. 35. interviews <ul><li>Real users when possible </li></ul><ul><li>You build what I asked for but that’s not what I want! </li></ul><ul><li>Just because they have the knowledge doesn’t mean they know the way to implement </li></ul><ul><ul><li>Complex mini-language lesson-  visual designer instead. </li></ul></ul>
    36. 36. Open ended and context free questions <ul><li>Would you like that app to be in a browser? </li></ul><ul><li>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? </li></ul><ul><li>How fast do searches need to be? </li></ul><ul><li>What performance is required? Is performance more important in some parts of the application? </li></ul>
    37. 37. Questionnaires <ul><li>Gather info on stories from bigger user base </li></ul><ul><li>Large number of answers for a specific question </li></ul><ul><li>Bad </li></ul><ul><ul><li>“What features would you like to see” </li></ul></ul><ul><ul><ul><li>Miss things if you give them a multiple choice </li></ul></ul></ul><ul><ul><ul><li>Hard to tabulate if open text </li></ul></ul></ul>
    38. 38. Story Writing Workshops <ul><li>Who </li></ul><ul><ul><li>Developers </li></ul></ul><ul><ul><li>Users </li></ul></ul><ul><ul><li>Product customer </li></ul></ul><ul><ul><li>Other stakeholders </li></ul></ul><ul><li>Low fidelity prototyping </li></ul><ul><ul><li>whiteboard, </li></ul></ul><ul><ul><li>Note cards </li></ul></ul><ul><ul><li>Paper </li></ul></ul><ul><li>Component layout </li></ul><ul><li>Throw away the low-fidelity prototype! </li></ul><ul><li>Access competitive products if you’re stuck! </li></ul>
    39. 39. Developer responsibilities <ul><li>Understand and use multiple techniques while trawling </li></ul><ul><li>Make best use of open ended and context free questions </li></ul>
    40. 40. Customer responsibilities <ul><li>Understand and use multiple techniques while trawling for stories </li></ul><ul><li>Writing as many stories as early as possible </li></ul><ul><li>Main representative of the software and responsible for options in communicating with them </li></ul><ul><li>If you need or want help responsible for scheduling and running story writing workshops </li></ul><ul><li>Responsible for making sure all roles are appropriately represented </li></ul>
    41. 41. Working with user proxies Chapter 5
    42. 42. Selecting user proxies <ul><li>It’s difficult to get all the right real users </li></ul><ul><ul><li>But important to try! </li></ul></ul><ul><li>Can’t get our user because of their manager (a helpdesk, NOC, etc) </li></ul><ul><ul><li>Bring manager in </li></ul></ul><ul><ul><li>Corroborate </li></ul></ul><ul><li>Development manager = worst proxy possible!  </li></ul><ul><li>Sales Person = bad proxy but great way to get introduced to good users. </li></ul>
    43. 43. Domain experts <ul><li>Great domain modelers </li></ul><ul><ul><li>Can put definitions to unique domain language </li></ul></ul><ul><ul><li>Identify business rules </li></ul></ul><ul><li>Real user better </li></ul><ul><ul><li>For interactions with the software </li></ul></ul>
    44. 44. Marketing group <ul><li>Focus on quantity of features rather than the quality of those features </li></ul><ul><li>Might not have insight to provide detail about those stories* </li></ul>
    45. 45. Former Users <ul><li>Experience will expire! </li></ul>
    46. 46. Customers <ul><li>Buyers not necessarily users! </li></ul>
    47. 47. Trainers and tech support <ul><li>Ease of training </li></ul><ul><li>Ease of supporting </li></ul><ul><li>Good goals, but what’s important? </li></ul>
    48. 48. Business or System analyst <ul><li>One foot in tech one foot in the domain. </li></ul><ul><li>Tendency to be forced into thinking the problem out instead of getting the information from the users. </li></ul><ul><li>3 weeks to figure out a story instead of a 2 hour session.* </li></ul>
    49. 49. What to do when working with proxy <ul><li>When users exist but access is limited </li></ul><ul><ul><li>User task force story writers under a proxy </li></ul></ul><ul><li>When there is no user available </li></ul><ul><ul><li>Use more than one </li></ul></ul><ul><ul><li>Competing products </li></ul></ul><ul><ul><li>Reviews of their products </li></ul></ul><ul><li>Can you do it yourself? </li></ul><ul><ul><li>Avoid it! </li></ul></ul><ul><ul><ul><li>Developers won’t have the ‘closeness’ with user-base </li></ul></ul></ul><ul><ul><ul><li>Even if Developers are the users! </li></ul></ul></ul><ul><ul><ul><ul><li>Especially if the Developers are the users! Cherry pick! </li></ul></ul></ul></ul><ul><li>Constituting the Customer team </li></ul><ul><ul><li>Put real users on the customer team! </li></ul></ul>
    50. 50. Dev responsibilities <ul><li>Organize and select appropriate customer </li></ul><ul><li>Understand how different user proxies can affect the system being built and influence the interactions. </li></ul>
    51. 51. Customer Responsibilities <ul><li>If you’re not the user, know the proxy type that describes you! </li></ul><ul><li>Understand what biases you may bring to the table and work towards overcoming them. </li></ul>
    52. 52. Acceptance Testing User Stories Chapter 6
    53. 53. Write tests before coding <ul><li>When? </li></ul><ul><ul><li>Capture specific details when talking </li></ul></ul><ul><ul><li>At the start of the iteration before programming begins </li></ul></ul><ul><ul><li>When new tests are discovered after the programming of a story </li></ul></ul><ul><li>Considerations </li></ul><ul><ul><li>What else would a programmer need? </li></ul></ul><ul><ul><li>What am I assuming? </li></ul></ul><ul><ul><li>Are there circumstances where this story will be different? </li></ul></ul><ul><ul><li>What could go wrong? </li></ul></ul>
    54. 54. Customer Team Specifies tests <ul><li>Because it’s their vision! </li></ul><ul><li>They can work with a programmer to create the tests. </li></ul><ul><li>Testers can augment the tests of course to better suite the need. </li></ul>
    55. 55. Testing is part of the process <ul><li>Not something you do “At the end” </li></ul><ul><li>Testers can’t learn of the system from the programmers. </li></ul><ul><li>In the process </li></ul><ul><ul><li>Write a test </li></ul></ul><ul><ul><li>Write code to support the test </li></ul></ul><ul><ul><li>Think of more tests. </li></ul></ul>
    56. 56. How many are too many? <ul><li>Continue to write as long as they add value or clarity to the story. </li></ul><ul><li>Good programming teams will have Unit Tests in place that handle low level things. </li></ul><ul><ul><li>i.e. feb 30 th not a real date </li></ul></ul>
    57. 57. Framework Integrated Test <ul><li>Spreadsheet/data table tests </li></ul><ul><li>Action tests </li></ul><ul><li>Requires test harness development (a programmer) </li></ul><ul><li>Requires decoupling from User interface </li></ul><ul><li>Fitnesse </li></ul><ul><ul><li>Wiki based execution of FIT tests </li></ul></ul>
    58. 58. Types of tests <ul><li>Mike Cohn’s ‘reason’ list </li></ul><ul><ul><li>User interface tests </li></ul></ul><ul><ul><li>Usability testing </li></ul></ul><ul><ul><li>Performance testing </li></ul></ul><ul><ul><li>Stress Testing </li></ul></ul><ul><li>Crystal Clear ‘how’ List </li></ul><ul><ul><li>GUI based acceptance (Expensive and slow) </li></ul></ul><ul><ul><li>GUI-less acceptance </li></ul></ul><ul><ul><li>Unit Tests </li></ul></ul>
    59. 59. Developer responsibilities <ul><li>Automating </li></ul><ul><li>Thinking of additional tests </li></ul><ul><li>Unit testing code so acceptance tests don’t need specified for low hanging fruit </li></ul>
    60. 60. Customer Team Responsibilities <ul><li>Responsible for acceptance tests </li></ul><ul><li>Responsible for executing tests </li></ul>
    61. 61. Guidelines for good stories Chapter 7
    62. 62. Start with goal stories <ul><li>Search for jobs </li></ul><ul><li>Automate search process so she doesn’t have to search manually each time </li></ul><ul><li>Make her resume available so that companies may search for her </li></ul><ul><li>Easily apply for any jobs she likes </li></ul>
    63. 63. Slice the cake <ul><li>When there’s a large story </li></ul><ul><ul><li>Developers will try to split it along technical lines </li></ul></ul><ul><ul><ul><li>Job seeker will fill out resume form </li></ul></ul></ul><ul><ul><ul><li>Resume form will be submitted to database </li></ul></ul></ul><ul><ul><li>Make sure to focus on business value </li></ul></ul><ul><ul><ul><li>A job seeker can submit a resume that includes only basic information such as name, address, education history. </li></ul></ul></ul><ul><ul><ul><li>A job seeker can submit a resume that includes all information an employer needs to see. </li></ul></ul></ul><ul><ul><li>This forces the developers to span the whole architecture earlier on in a simpler manner </li></ul></ul><ul><ul><ul><li>Reduces risk </li></ul></ul></ul><ul><ul><ul><li>Focus on working software/shippable product! </li></ul></ul></ul>
    64. 64. Write closed stories <ul><li>Have a clear goal being met with the story </li></ul><ul><ul><li>Bad </li></ul></ul><ul><ul><ul><li>A recruiter can manage the ad she has placed </li></ul></ul></ul><ul><ul><li>Good </li></ul></ul><ul><ul><ul><li>A recruiter can review resumes from applicants to one of her ads </li></ul></ul></ul><ul><ul><ul><li>A recruiter can change the recruiter date of an ad </li></ul></ul></ul><ul><ul><ul><li>A recruiter can delete an application that is not a good match for a job </li></ul></ul></ul>
    65. 65. Put constraints on cards <ul><li>Something that must be observed, not implemented. </li></ul><ul><ul><li>The system must support peak usage of up to 50 concurrent users </li></ul></ul><ul><ul><li>Do not make it hard to internationalize the software if needed later </li></ul></ul><ul><ul><li>The new system must use our existing order database </li></ul></ul>
    66. 66. Size stories to the horizon <ul><li>A job seeker can post a resume </li></ul><ul><li>A job seeker can search job openings </li></ul><ul><li>A recruiter can post a job opening </li></ul><ul><li>A recruiter can search resumes </li></ul><ul><li>Focus on posting resumes first! </li></ul><ul><ul><li>Add resume, edit resume, remove resume, mark inactive, mark hidden, see how many views. </li></ul></ul>
    67. 67. Keep the UI out as long as possible <ul><li>Mixing requirements with solution specification! </li></ul>
    68. 68. Some things aren’t stories <ul><li>In a few cases, such as external vendor </li></ul><ul><ul><li>Screen mock </li></ul></ul><ul><ul><li>Use case </li></ul></ul><ul><ul><li>UML Diagram </li></ul></ul><ul><ul><li>Specification </li></ul></ul><ul><ul><li>etc </li></ul></ul>
    69. 69. Include user roles in stories <ul><li>as a (role) I want (function) because (business value) </li></ul>
    70. 70. Write for one user <ul><li>Job seeker can remove a resume </li></ul><ul><li>Job seeker can remove her own resume </li></ul>
    71. 71. Write in active voice <ul><li>Bad </li></ul><ul><ul><li>A resume can be posted by a job seeker </li></ul></ul><ul><li>Good </li></ul><ul><ul><li>A job seeker can post a resume </li></ul></ul>
    72. 72. Customer writes <ul><li>Not developer </li></ul><ul><ul><li>But they can suggest </li></ul></ul><ul><ul><ul><li>Which maybe is write them then get signoff </li></ul></ul></ul><ul><ul><li>Offer advice </li></ul></ul><ul><li>In the end the customer has to prioritize them so they need to know the language on the card fully. </li></ul>
    73. 73. Don’t number the cards <ul><li>Pointless over head </li></ul><ul><li>You’ll be shredding cards and creating cards often </li></ul>
    74. 74. Don’t forget the purpose <ul><li>Reminder about the requirements not the document of the requirements. </li></ul><ul><li>Don’t replace the conversation by adding the detail. </li></ul>
    75. 75. Estimating and Planning PART II
    76. 76. Estimating stories Chapter 8
    77. 77. Story points <ul><li>Relative to eachother </li></ul><ul><li>Nebulous units of time (NUTs) </li></ul><ul><li>Ideal days </li></ul><ul><li>Easier than estimating time. </li></ul><ul><ul><li>How many centimeters are in this line </li></ul></ul><ul><ul><li>How ‘big’ is this line </li></ul></ul><ul><ul><li>Where is halfway on this line </li></ul></ul><ul><ul><li>Where is 1 quarter on this line </li></ul></ul>
    78. 78. Estimate as a team <ul><li>Who is ‘the team’ </li></ul><ul><ul><li>Everyone who’s going to do the work. </li></ul></ul><ul><li>Collective ownership </li></ul><ul><ul><li>Won’t know who will do the work </li></ul></ul><ul><li>Less chance for sandbagging or low-balling </li></ul><ul><li>Customer does not interfere with estimate, but can contribute** </li></ul>
    79. 79. Estimating <ul><li>Hear about the story </li></ul><ul><li>Ask as many questions as needed to know what is needed </li></ul><ul><li>Write estimate on on cards or use existing cards </li></ul><ul><li>All show estimate </li></ul><ul><li>Talk about why the low and the high </li></ul><ul><li>Re-bid </li></ul><ul><li>If the team cannot come to consensus then “Do something”** </li></ul>
    80. 80. Everything takes 4 hours <ul><li>Keep in mind everything that has to happen to complete the story. </li></ul><ul><ul><li>Unit test </li></ul></ul><ul><ul><li>Refactoring </li></ul></ul><ul><ul><li>Talking to the customer </li></ul></ul><ul><ul><li>Enterprise specific “stuff” </li></ul></ul><ul><ul><li>Code review </li></ul></ul><ul><ul><li><Your organization/team/customers definition of “DONE”> </li></ul></ul>
    81. 81. Triangulate <ul><li>Refer to other stories you’ve already estimated. </li></ul>
    82. 82. Using points as team velocity <ul><li>Check ‘yesterdays weather’ </li></ul><ul><li>Don’t take more than that </li></ul><ul><ul><li>Maybe stretch tasks** </li></ul></ul>
    83. 83. What if we’re pair programming? <ul><li>Ideal pair days </li></ul><ul><li>“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) </li></ul>
    84. 84. Precision decreases as size increases <ul><li>½,1,2,3,5,8,13,20,40,80 </li></ul><ul><ul><li>Don’t have to think about is it a 79 or 80 </li></ul></ul>
    85. 85. confusions <ul><li>Not equivalent to any other team’s points </li></ul><ul><li>Sum of smaller stories will not equal the theme or epic they came from </li></ul><ul><li>Sum of tasks will not be equal to the estimate of the initial story. </li></ul>
    86. 86. Customer responsibillities <ul><li>Answer questions </li></ul><ul><li>Don’t estimate </li></ul><ul><li>Don’t urge lower/higher estimates </li></ul>
    87. 87. Developer responsibilities <ul><li>Define story points in a manner that are relavent and sticking with that definition </li></ul><ul><li>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. </li></ul><ul><li>Pair programming doesn’t affect points only affects team velocity. </li></ul>
    88. 88. Planning a release Chapter 9
    89. 89. When do we want to release? <ul><li>Setup the buckets to put stories in for a release and then put dates on them. </li></ul><ul><ul><li>In scrumworks as you begin to burn down you’ll see how you faire with that date. </li></ul></ul><ul><ul><li>You can plan based on team velocity (if established) </li></ul></ul><ul><ul><ul><li>You can guess a team velocity. </li></ul></ul></ul>
    90. 90. What would you like it in <ul><li>Must have </li></ul><ul><li>Should have </li></ul><ul><li>Could have </li></ul><ul><li>Won’t have this time </li></ul>
    91. 91. Prioritizing stories <ul><li>But they’re all #1 priority!  </li></ul><ul><li>The risk </li></ul><ul><li>Impact to other stories </li></ul><ul><li>Desirability to broad base of users </li></ul><ul><li>Desirability to small but important base of users! </li></ul><ul><li>Cohesiveness of a story to another story (not dependency, see INVEST) </li></ul><ul><li>Developers will have a preference of implementation path. Customer wins these. </li></ul>
    92. 92. Cost Changes Priority <ul><li>Enter key to move between fields because of DOS** </li></ul><ul><li>So: customer can choose and we have to give them visibility into what will happen with their choices. </li></ul>
    93. 93. Risky Stories <ul><li>Juicy bits first! </li></ul><ul><li>Visibility into the risks. </li></ul><ul><ul><li>If you develop this story before this other story then there is “this” risk. </li></ul></ul>
    94. 94. Prioritizing Infrastructure <ul><li>Be able to generate 50 stock images per second. </li></ul><ul><li>If something like this is lower priority talk about the infrastructure need and how hard it is to refactor. </li></ul>
    95. 95. Iteration Length <ul><li>Avoid random changes to iteration length </li></ul><ul><li>Longer = less over head </li></ul><ul><li>Shorter = less chance for development to go off the rails. </li></ul><ul><li>No longer than a month </li></ul><ul><li>No shorter than a week. </li></ul><ul><li>Scrum = 30 days </li></ul><ul><li>XP = 1-2 weeks </li></ul><ul><li>It’s good to sync up with other teams in the organization. </li></ul><ul><ul><li>Evolve a culture that supports planning meetings, standups, and demo-days </li></ul></ul>
    96. 96. From points to duration <ul><li>100 points </li></ul><ul><li>Iteration of 1 week was 10 pnts </li></ul><ul><li>10 weeks </li></ul>
    97. 97. Initial velocity <ul><li>Do an initial iteration and use that as velocity </li></ul><ul><ul><li>Iteration 0 </li></ul></ul><ul><li>Use historical values </li></ul><ul><li>Take a guess! </li></ul><ul><ul><li>Hopefully stories are small enough to guess how much time they’ll take. </li></ul></ul>
    98. 98. Creating the release plan <ul><li>Pin to the wall </li></ul><ul><li>Spreadsheet </li></ul><ul><li>Photocopied stories </li></ul><ul><li>Gannt charts </li></ul><ul><ul><li>Iteration 1 </li></ul></ul><ul><ul><ul><li>Story 1 </li></ul></ul></ul><ul><ul><ul><li>Story 2 </li></ul></ul></ul><ul><ul><li>Iteration 2 </li></ul></ul><ul><ul><ul><li>Story 3 </li></ul></ul></ul><ul><ul><ul><li>Story 4 </li></ul></ul></ul>
    99. 99. Warning <ul><li>Be careful of saying “we’ll be done june 4 th ” </li></ul><ul><li>Say we’ll be done in 7-9 iterations. </li></ul><ul><li>Especially during first few releases </li></ul><ul><li>Especially if the team composition changes alot </li></ul>
    100. 100. Developer responsibilities <ul><li>Provide info to prioritize </li></ul><ul><ul><li>Risks </li></ul></ul><ul><ul><li>Infrastructure </li></ul></ul><ul><li>Create release plan based on realistic estimates </li></ul><ul><ul><li>Appropriate project buffer (deployment concerns, etc) </li></ul></ul>
    101. 101. Customer Responsibilities <ul><li>Prioritize stories into precise order you value them. </li></ul><ul><ul><li>Not just stacks of high, medium, low. </li></ul></ul><ul><li>Expressing honest deadlines </li></ul><ul><ul><li>Don’t say june 15 th to be safe if august 15 th is ok </li></ul></ul><ul><li>Understand difference between ideal time and calendar time </li></ul><ul><li>Split stories that contain components you want to prioritize differently. </li></ul><ul><li>Understand when a single developer has less velocity than another. </li></ul>
    102. 102. Planning an iteration Chapter 10
    103. 103. Iteration plan overview <ul><li>Discuss a story </li></ul><ul><li>Disaggregate the story into tasks (decompose) </li></ul><ul><li>One developer accepts responsibility for each task </li></ul><ul><li>Estimate the tasks, ensure they’re not overcommitted. </li></ul>
    104. 104. Discuss the story <ul><li>Customer start with highest priority story </li></ul><ul><li>Ask questions until they understand enough to break it into tasks (don’t need the complete detail of everything in the world!) </li></ul><ul><ul><li>Not everyone needs the gross detail </li></ul></ul><ul><ul><li>The dev can work with the customer to get the detail once they’re on the task </li></ul></ul><ul><li>Changing priorities </li></ul><ul><ul><li>Implementations of database** </li></ul></ul>
    105. 105. Decompose to tasks <ul><li>No art, but stuff imagine this story: “A user can search for a hotel on various fields” </li></ul><ul><ul><li>Code basic search screen </li></ul></ul><ul><ul><li>Code advanced search screen </li></ul></ul><ul><ul><li>Code results screen </li></ul></ul><ul><ul><li>Write and tune sql to query for basic searches </li></ul></ul><ul><ul><li>Write and tune sql to query for advanced searches </li></ul></ul><ul><ul><li>Document new functionality in help system and users guide </li></ul></ul>
    106. 106. Guidelines <ul><li>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’) </li></ul><ul><li>Separate tasks by developers </li></ul><ul><li>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) </li></ul>
    107. 107. Accepting Responsibility <ul><li>Write them up, someone accepts and owns. </li></ul><ul><li>Everyone’s responsibility to make sure the tasks gets done “we’re all in this together” </li></ul><ul><li>No one should say “well I finished my work but Tom has tasks left” </li></ul>
    108. 108. Estimate and confirm <ul><li>By this point tasks should be small enough to be reliable </li></ul><ul><li>If not, don’t worry, guess and move on. </li></ul><ul><li>Add up the ideal hours and see if it’s realistic. </li></ul><ul><ul><li>Let someone take something </li></ul></ul><ul><ul><li>Hope for the best </li></ul></ul><ul><ul><li>Drop a story </li></ul></ul>
    109. 109. Developer responsibilities <ul><li>Participate in iteration planning </li></ul><ul><li>Responsible for decomposing into tasks, NOT just the stories you’re going to work on. </li></ul><ul><li>Accepting responsibility for tasks you will work on </li></ul><ul><li>Ensuring you take the appropriate amount of work </li></ul><ul><li>Monitoring the amount of work you have left and your teammates work. If you’re likely to finish early, help your teammate. </li></ul>
    110. 110. Customer responsibilities <ul><li>Prioritize stories </li></ul><ul><li>Directing developers toward best business value you can. If higher values have come to light since. Adjust priority. </li></ul><ul><li>Participate in iteration planning to field questions. </li></ul>
    111. 111. Measuring and monitoring velocity <ul><li>Measuring </li></ul><ul><ul><li>Planned vs actual </li></ul></ul><ul><ul><li>Burndown charts </li></ul></ul><ul><ul><li>Hours remaining NOT expended </li></ul></ul><ul><li>Monitoring </li></ul><ul><ul><li>Information Radiators** </li></ul></ul><ul><ul><li>Task board </li></ul></ul><ul><ul><li>Burn board </li></ul></ul><ul><ul><li>Impediment Board </li></ul></ul>
    112. 112. Developer responsibilities <ul><li>Complete a story before moving onto the next. </li></ul><ul><li>Understand impact any decision you make on the velocity of the project </li></ul><ul><li>Understand how to read the charts </li></ul><ul><li>If manager/tracker understand when to produce the charts and how. </li></ul>
    113. 113. Customer Responsibilities <ul><li>Understand how to read and interpret the charts shown in this chapter </li></ul><ul><li>Know the velocity of the team </li></ul><ul><li>Know the actual velocity and how it compares to planned velocity and whether to correct. </li></ul><ul><li>Add or remove stories from the release to ensure objectives are met. </li></ul>
    114. 114. Part III FAQ
    115. 115. Stories aren’t IEEE830 <ul><li>The system shall </li></ul><ul><ul><li>The system shall </li></ul></ul><ul><ul><li>The system shall </li></ul></ul><ul><ul><li>The system shall </li></ul></ul><ul><li>Focus on the user and interactions! </li></ul>
    116. 116. Stories aren’t use cases <ul><li>Use case is generally larger scope </li></ul><ul><li>Stories differ in level of completeness. </li></ul><ul><ul><li>A use case has the tests before it’s finished </li></ul></ul><ul><ul><li>A story delays the acceptance until the last possible moment before implementation saving time. </li></ul></ul>
    117. 117. Stories aren’t scenarios <ul><li>Scenario </li></ul><ul><ul><li>Setting </li></ul></ul><ul><ul><li>Actors </li></ul></ul><ul><ul><li>Goals/objectives </li></ul></ul><ul><ul><li>Actions/events </li></ul></ul><ul><li>Story </li></ul><ul><ul><li>A role </li></ul></ul><ul><ul><li>An objective/goal </li></ul></ul><ul><ul><li>A value </li></ul></ul><ul><ul><li>C C C (card conversation complete) </li></ul></ul>
    118. 118. Why use? <ul><li>Emphasize verbal communication </li></ul><ul><li>Comprehensible by everyone </li></ul><ul><li>Right size for planning </li></ul><ul><li>Work for IID </li></ul><ul><li>Encourage deferring detail (less waste) </li></ul><ul><li>Support opportunistic design </li></ul><ul><ul><li>Know it when I see it! </li></ul></ul><ul><li>Participatory design </li></ul><ul><li>Build tacit knowledge (explicit, tacit, externalize, combine, internalize) </li></ul><ul><ul><li>Face it, who really reads the requirements?  </li></ul></ul>
    119. 119. Developer responsibilities <ul><li>Understand why we choose a technique </li></ul><ul><li>Understand advantages of other requirements techniques and when to apply them. </li></ul><ul><ul><li>Use case </li></ul></ul><ul><ul><li>Diagrams </li></ul></ul><ul><ul><li>Uml models </li></ul></ul><ul><ul><li>Domain models </li></ul></ul>
    120. 120. Catalog of story smells <ul><li>Too small </li></ul><ul><ul><li>Need to revise estimates </li></ul></ul><ul><li>Interdependent </li></ul><ul><ul><li>Hard to plan because of dependencies </li></ul></ul><ul><li>Goldplating </li></ul><ul><ul><li>Adding unplanned features or interpreting stories </li></ul></ul><ul><li>Too many details </li></ul><ul><ul><li>Too much time spent on gathering befor eimplementing Something! </li></ul></ul><ul><li>Including UI too soon </li></ul><ul><ul><li>Details about specific ui things (dropdowns, tabs) </li></ul></ul><ul><li>Thinking too far ahead </li></ul><ul><ul><li>Hard to fit on cards </li></ul></ul><ul><li>Splitting too many stories during planning to ‘fit’ </li></ul><ul><li>Trouble prioritizing </li></ul><ul><ul><li>Missing biz value? </li></ul></ul><ul><ul><li>Too big? </li></ul></ul><ul><ul><li>A little of this and of that? </li></ul></ul><ul><li>Customer won’t write/prioritize </li></ul><ul><ul><li>Let them off the hook somehow </li></ul></ul>
    121. 121. Using stories with Scrum <ul><li>30 day iteration </li></ul><ul><li>Scrum team </li></ul><ul><ul><li>4-7 </li></ul></ul><ul><ul><li>Cross functional (dev, test, business, other) </li></ul></ul><ul><li>Product Backlog (uncommitted) </li></ul><ul><ul><li>List of stories prioritized and estimated </li></ul></ul><ul><li>Sprint planning </li></ul><ul><ul><li>Select top priority subset and COMMIT </li></ul></ul><ul><li>Sprint Review </li></ul><ul><ul><li>Show off the completed functionality </li></ul></ul><ul><ul><li>Define DONE first </li></ul></ul><ul><ul><li>Review completed stories for completeness </li></ul></ul><ul><ul><li>Review uncompleted stories to verify they’re NOT in the demo </li></ul></ul><ul><li>Daily Scrum (standup) </li></ul><ul><ul><li>What did you do since last scrum? </li></ul></ul><ul><ul><li>What are you working on after this scrum? </li></ul></ul><ul><ul><li>What’s in your way? </li></ul></ul>
    122. 122. Additional topics <ul><li>Paper or software? </li></ul><ul><li>Stories and interface? </li></ul><ul><ul><li>If important make a UI constraint </li></ul></ul><ul><ul><li>Write two  </li></ul></ul><ul><li>Retaining stories </li></ul><ul><li>Stories for bugs </li></ul><ul><li>Colored cards? </li></ul>

    ×