Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.
Agile with SCRUM Overview and User Stories Peter Saddington, CSM CSP Enterprise Agile Coach Executive Editor AgileScout.co...
White Barrel LLC. © 2011 Peter Saddington Peter Saddington, CSP CSM Independent Enterprise Agile Coach Rally Software Agil...
Before we begin… A Standup! <ul><li>Let’s take a moment to introduce ourselves. </li></ul><ul><li>What’s your name & proje...
Free Swag = #win! White Barrel LLC. © 2010 Peter Saddington www.scrumpocketguide.com
Agile Manifesto <ul><li>Individuals and interactions over processes and tools </li></ul><ul><li>Working software over comp...
Distilled Principles of Agile Manifesto <ul><li>Priority is to satisfy the customer </li></ul><ul><li>Deliver working soft...
Process Frameworks <ul><li>Waterfall </li></ul>White Barrel LLC. © 2011 Peter Saddington
Process Frameworks <ul><li>Iterative </li></ul>White Barrel LLC. © 2011 Peter Saddington
Process Frameworks <ul><li>Agile </li></ul>White Barrel LLC. © 2011 Peter Saddington
Agile vs Scrum vs Other Frameworks <ul><li>Agile is a mindset, there are several ways to implement Agile: </li></ul><ul><u...
Scrum <ul><li>Scrum is not an acronym, but a strategy in the game of rugby for getting an out-of-play ball back into play....
Exercise – Batch vs Flow  <ul><li>Four volunteers, please! </li></ul><ul><li>Round 1 </li></ul><ul><li>Each person flips a...
Scrum Rules <ul><li>Scrum is a set of rules, procedures, and practices </li></ul><ul><li>Improve the development environme...
Scrum Approach <ul><li>Work together as a whole team </li></ul><ul><li>Focus on business priorities </li></ul><ul><li>Time...
<ul><li>The Chicken and the Pig – A Story: </li></ul><ul><li>Bacon and Egg Restaurant </li></ul><ul><li>Chickens involved…...
How It All Starts <ul><li>A Scrum project starts with a vision of the system or product to be developed </li></ul><ul><li>...
Scrum Roles <ul><li>Product Owner </li></ul><ul><ul><li>The single customer voice who establishes the vision, prioritizes ...
Scrum Meetings <ul><li>Daily Scrum </li></ul><ul><li>Sprint Planning Meeting </li></ul><ul><li>Sprint Review Meeting* </li...
Scrum Artifacts <ul><li>User Stories </li></ul><ul><li>Product Backlog </li></ul><ul><ul><li>List of functional and non-fu...
The Bottom Line <ul><li>Scrum is: </li></ul><ul><ul><li>Doing the simplest thing possible </li></ul></ul><ul><ul><li>Getti...
Final Thoughts <ul><li>The core of Agile is the team </li></ul><ul><li>Focus on the priorities first (most valuable) </li>...
User Stories – Better Practices A Quick Guide to Story Creation in Scrum Peter Saddington CSM, CSP Agile Scrum Coach
A Worldview White Barrel LLC © 2010 Peter Saddington
Roadmap White Barrel LLC © 2010 Peter Saddington
Why Not Requirements Documents? <ul><li>Complete specifications: </li></ul><ul><li>Assume everything is knowable in advanc...
User Stories are a Conversation <ul><li>User stories are: </li></ul><ul><li>User or customer need </li></ul><ul><li>Produc...
User Stories Facilitate Conversation <ul><li>User*  – How do I describe what I want? </li></ul><ul><li>Stakeholder  – What...
<ul><li>Easy to understand  – Makes sense to the reader </li></ul><ul><li>A (software/system) requirement  </li></ul><ul><...
White Barrel LLC © 2010 Peter Saddington User Story Process Step #1 Step #2 Step #3
<ul><li>Define the user personas! </li></ul><ul><li>What different types of customers/consumers interact with the system? ...
<ul><li>User Roles </li></ul><ul><ul><li>Various types of user personas </li></ul></ul><ul><li>Role Modeling </li></ul><ul...
<ul><li>Scenario :  You need to create a simple login and preferences mechanism for your corporate Twitter account </li></...
White Barrel LLC © 2010 Peter Saddington Persona Definition Documentation?
Roadmap White Barrel LLC © 2010 Peter Saddington
Story Creation - Guidelines <ul><li>Stakeholders  write user stories </li></ul><ul><li>Remember non-functional requirement...
Non-Functional Requirements <ul><li>Non-functional requirements should often be considered “constraints” on a system </li>...
INVEST Model <ul><li>I ndependent  – One user story should be independent of another (as much as possible). Dependencies b...
Ron Jeffries 3 C’s <ul><li>Card  – Stories written on note cards with annotations as needed (estimates, notes, etc) </li><...
Four Main Components of a Story <ul><li>( Given ( AS A ) ) –  “As a business owner…” / “Given a new list…” </li></ul><ul><...
1. Given <ul><li>( Given ( AS A ) ) –  “As a business owner…” / “Given a new list…” </li></ul><ul><li>We want users to be ...
2. When <ul><li>( When ( I WANT ) ) –  “I’d like the ability to…” / “We need a function to…” / “When a customer clicks on…...
3. Then <ul><li>( Then ( SO THAT ) ) –  “So that I can…” / “So that the customer can…” / “Then the customer should see…” /...
4. Acceptance Criteria <ul><li>( Acceptance Criteria ) – Verifiable and testable criteria that can be tested based on THEN...
4a. Acceptance Stories <ul><li>( Acceptance Stories ) – Verifiable and testable criteria written in acceptance test form. ...
4b. Acceptance Confirmation <ul><li>( Acceptance Confirmation ) – Verifiable and testable criteria written in “Success” an...
Exercise – 99 Balloons <ul><li>Let’s form some teams! </li></ul><ul><li>Round 1 </li></ul><ul><li>Recreate my balloon with...
<ul><li>User Interviews </li></ul><ul><ul><li>Select right interviewees </li></ul></ul><ul><ul><li>Ask open-ended, context...
<ul><li>Scenario :  You need to create a simple login and preferences mechanism for your corporate Twitter account </li></...
Roadmap White Barrel LLC © 2010 Peter Saddington
Product Backlog to Release Backlog <ul><li>A prioritized list of features for the given product </li></ul><ul><li>Stories ...
Prioritization Factors to Consider <ul><li>Financial value of features </li></ul><ul><li>Costs of implementation </li></ul...
MoSCoW Method <ul><li>M  – MUST have (Critical for success) </li></ul><ul><li>S  – SHOULD have if possible (If not time cr...
M & S of MoSCoW <ul><li>M  – MUST have (Critical for success) </li></ul><ul><ul><li>Essential - key stakeholders needs wil...
C & W of MoSCoW <ul><li>C  – COULD have if it does not affect anything else (Include if little development cost) </li></ul...
Kano’s Model of Quality <ul><li>Objective and Subjective Quality </li></ul><ul><li>Must-haves – Same as “M” in MoSCoW </li...
Kano’s Model - Example <ul><li>In Agile – Objective quality is non-negotiable </li></ul><ul><li>Subjective quality – Perce...
Prioritization Sliders White Barrel LLC. © 2010 Peter Saddington
<ul><li>Manage the backlog by: </li></ul><ul><ul><li>Sorting stories by user persona </li></ul></ul><ul><ul><li>Sorting st...
<ul><li>Scenario :  You need to create a simple login and preferences mechanism for your corporate Twitter account </li></...
Roadmap White Barrel LLC © 2010 Peter Saddington
Themes to Tasks White Barrel LLC © 2010 Peter Saddington
Tasks Warm Up Exercise <ul><li>What are all the things you did to get ready to be at work today? </li></ul><ul><li>Startin...
Tasks vs Tools Exercise <ul><li>Share with the group some example lists </li></ul><ul><li>What are common themes and tasks...
Goals, Tasks, Tools White Barrel LLC © 2010 Peter Saddington
User Stories are Tasks or Tools White Barrel LLC © 2010 Peter Saddington
Stories Satisfy User NEEDS First! White Barrel LLC © 2010 Peter Saddington
<ul><li>Start with specific personas </li></ul><ul><li>Write closed stories first </li></ul><ul><li>Write stories collabor...
Exercise – Creating at a Story <ul><li>Ta ke a current feature your team is aware of  </li></ul><ul><li>Each team member w...
Roadmap White Barrel LLC © 2010 Peter Saddington
Epic User Stories <ul><li>Causes for Story Size </li></ul><ul><li>Stories cover too much information </li></ul><ul><li>Sto...
Breaking Up Epics <ul><li>Split  – Slice stories up into different scenarios </li></ul><ul><li>Spike – Too many unknowns? ...
Splitting for Value - Three Rules  <ul><li>When breaking down epics, remember: </li></ul><ul><li>Split stories for value –...
Exercise – Breaking Up Epics <ul><li>Let’s take an example from our existing backlog </li></ul>White Barrel LLC © 2010 Pet...
Suggestions for Splitting Up Epics <ul><li>Handle empty scenarios and core functions first </li></ul><ul><li>Happy path, t...
Roadmap White Barrel LLC © 2010 Peter Saddington
Notes on Bug or Issue Tracking <ul><li>Steps to Reproduce / Recreate the Bug </li></ul><ul><li>Actual Results </li></ul><u...
Exercise – Baseline Story Estimation <ul><li>Different Stories in different sizes (1,2,3,5,8…) </li></ul><ul><li>What was ...
Questions? White Barrel LLC © 2010 Peter Saddington
Upcoming SlideShare
Loading in …5
×

Agile and user story workshop Peter Saddington

33,923 views

Published on

A workshop for better practices in User Story Writing using Agile and Scrum

Published in: Business, Technology
  • What a simplest way of explaining each entertaining terminology of agile !! Intriguing !!
       Reply 
    Are you sure you want to  Yes  No
    Your message goes here

Agile and user story workshop Peter Saddington

  1. 1. Agile with SCRUM Overview and User Stories Peter Saddington, CSM CSP Enterprise Agile Coach Executive Editor AgileScout.com @agilescout
  2. 2. White Barrel LLC. © 2011 Peter Saddington Peter Saddington, CSP CSM Independent Enterprise Agile Coach Rally Software Agile Coach Executive Editor AgileScout.com Author – Scrum Pocket Guide [email_address] +1.404.669.6662 www.agilescout.com www.scrumpocketguide.com Twitter: @agilescout
  3. 3. Before we begin… A Standup! <ul><li>Let’s take a moment to introduce ourselves. </li></ul><ul><li>What’s your name & project you’re working on? </li></ul><ul><li>What is your level of experience with Agile? </li></ul><ul><li>What do you hope to learn in this workshop? </li></ul><ul><li>Write questions on Sticky notes as they occur to you and affix them to our Learning Backlog . </li></ul>White Barrel LLC. © 2011 Peter Saddington
  4. 4. Free Swag = #win! White Barrel LLC. © 2010 Peter Saddington www.scrumpocketguide.com
  5. 5. Agile Manifesto <ul><li>Individuals and interactions over processes and tools </li></ul><ul><li>Working software over comprehensive documentation </li></ul><ul><li>Customer collaboration over contract negotiation </li></ul><ul><li>Responding to change over following a plan </li></ul>White Barrel LLC. © 2011 Peter Saddington www.agilemanifesto.org
  6. 6. Distilled Principles of Agile Manifesto <ul><li>Priority is to satisfy the customer </li></ul><ul><li>Deliver working software frequently </li></ul><ul><li>Business and development work together </li></ul><ul><li>Working software is primary measure of success </li></ul><ul><li>The team regularly reflects on work </li></ul><ul><li>Build projects around motivated people </li></ul>White Barrel LLC. © 2011 Peter Saddington
  7. 7. Process Frameworks <ul><li>Waterfall </li></ul>White Barrel LLC. © 2011 Peter Saddington
  8. 8. Process Frameworks <ul><li>Iterative </li></ul>White Barrel LLC. © 2011 Peter Saddington
  9. 9. Process Frameworks <ul><li>Agile </li></ul>White Barrel LLC. © 2011 Peter Saddington
  10. 10. Agile vs Scrum vs Other Frameworks <ul><li>Agile is a mindset, there are several ways to implement Agile: </li></ul><ul><ul><li>XP – Extreme Programming </li></ul></ul><ul><ul><li>DSDM – Dynamic Systems Development Method </li></ul></ul><ul><ul><li>Scrum – lightweight team centric processes </li></ul></ul><ul><ul><li>Lean – Manufacturing processes applied to software </li></ul></ul><ul><ul><li>FDD – Feature centric processes </li></ul></ul>White Barrel LLC. © 2011 Peter Saddington
  11. 11. Scrum <ul><li>Scrum is not an acronym, but a strategy in the game of rugby for getting an out-of-play ball back into play. </li></ul>White Barrel LLC. © 2011 Peter Saddington
  12. 12. Exercise – Batch vs Flow <ul><li>Four volunteers, please! </li></ul><ul><li>Round 1 </li></ul><ul><li>Each person flips all pennies </li></ul><ul><li>When done with entire batch, pass to next person </li></ul><ul><li>Round 2 </li></ul><ul><li>Each person flip one penny and pass to next person </li></ul><ul><li>Keep flipping and passing until done </li></ul><ul><li>Round 3 </li></ul><ul><li>Each table creates their own rules to maximize penny flow/throughput in least amount of time </li></ul>White Barrel LLC. © 2011 Peter Saddington
  13. 13. Scrum Rules <ul><li>Scrum is a set of rules, procedures, and practices </li></ul><ul><li>Improve the development environment </li></ul><ul><li>Reduce organizational overheads </li></ul><ul><li>Ensure iterative deliverables match user requirements </li></ul>White Barrel LLC. © 2011 Peter Saddington
  14. 14. Scrum Approach <ul><li>Work together as a whole team </li></ul><ul><li>Focus on business priorities </li></ul><ul><li>Time box short sprints and releases </li></ul><ul><li>Commit and deliver value incrementally </li></ul>White Barrel LLC. © 2011 Peter Saddington
  15. 15. <ul><li>The Chicken and the Pig – A Story: </li></ul><ul><li>Bacon and Egg Restaurant </li></ul><ul><li>Chickens involved… </li></ul><ul><li>Pigs are committed! </li></ul>White Barrel LLC. © 2011 Peter Saddington
  16. 16. How It All Starts <ul><li>A Scrum project starts with a vision of the system or product to be developed </li></ul><ul><li>The vision might be vague at first… </li></ul><ul><li>Perhaps stated in market terms rather than system terms… </li></ul><ul><li>But it will become clearer as the project moves forward </li></ul>White Barrel LLC. © 2011 Peter Saddington
  17. 17. Scrum Roles <ul><li>Product Owner </li></ul><ul><ul><li>The single customer voice who establishes the vision, prioritizes the work and defines success criteria </li></ul></ul><ul><li>ScrumMaster </li></ul><ul><ul><li>The situational leader who empowers the team, facilitates the process, and removes impediments </li></ul></ul><ul><li>Cross-functional team </li></ul><ul><ul><li>The people who deliver the customer value </li></ul></ul>White Barrel LLC. © 2011 Peter Saddington
  18. 18. Scrum Meetings <ul><li>Daily Scrum </li></ul><ul><li>Sprint Planning Meeting </li></ul><ul><li>Sprint Review Meeting* </li></ul><ul><li>Demo </li></ul><ul><li>Sprint Retrospective </li></ul>White Barrel LLC. © 2011 Peter Saddington
  19. 19. Scrum Artifacts <ul><li>User Stories </li></ul><ul><li>Product Backlog </li></ul><ul><ul><li>List of functional and non-functional requirements </li></ul></ul><ul><li>Sprint Backlog </li></ul><ul><ul><li>Prioritized list of stories for a given sprint </li></ul></ul><ul><li>Sprint Burndown Chart </li></ul><ul><ul><li>A chart showing completion of stories over time </li></ul></ul><ul><li>Definition of done </li></ul>White Barrel LLC. © 2011 Peter Saddington
  20. 20. The Bottom Line <ul><li>Scrum is: </li></ul><ul><ul><li>Doing the simplest thing possible </li></ul></ul><ul><ul><li>Getting a team what it needs and getting out of their way </li></ul></ul><ul><ul><li>Removing any obstacle that is preventing a team from being productive and efficient </li></ul></ul>White Barrel LLC. © 2011 Peter Saddington
  21. 21. Final Thoughts <ul><li>The core of Agile is the team </li></ul><ul><li>Focus on the priorities first (most valuable) </li></ul><ul><li>Communication </li></ul><ul><li>Document throughout the process instead of all up front </li></ul><ul><li>Review, review, review </li></ul><ul><li>Define the “done.” </li></ul>White Barrel LLC. © 2011 Peter Saddington
  22. 22. User Stories – Better Practices A Quick Guide to Story Creation in Scrum Peter Saddington CSM, CSP Agile Scrum Coach
  23. 23. A Worldview White Barrel LLC © 2010 Peter Saddington
  24. 24. Roadmap White Barrel LLC © 2010 Peter Saddington
  25. 25. Why Not Requirements Documents? <ul><li>Complete specifications: </li></ul><ul><li>Assume everything is knowable in advance </li></ul><ul><li>Are time-consuming to write and tedious to read </li></ul><ul><li>Treat learning as a “Change of Scope” </li></ul><ul><li>Don’t lend themselves to iterative, incremental delivery process </li></ul>White Barrel LLC © 2010 Peter Saddington
  26. 26. User Stories are a Conversation <ul><li>User stories are: </li></ul><ul><li>User or customer need </li></ul><ul><li>Product description </li></ul><ul><li>Used for planning </li></ul><ul><li>A conversation piece </li></ul>White Barrel LLC © 2010 Peter Saddington
  27. 27. User Stories Facilitate Conversation <ul><li>User* – How do I describe what I want? </li></ul><ul><li>Stakeholder – What do I need in my product to be successful? </li></ul><ul><li>PM – How do I track and schedule this work? </li></ul><ul><li>BA – What are the details of this feature? </li></ul><ul><li>UX – How do I understand the users needs? </li></ul><ul><li>Developer – What are the details of the tasks I need to work on today? </li></ul><ul><li>QA – How do I validate this completed work? </li></ul>White Barrel LLC © 2010 Peter Saddington Adapted from Jeff Patton www.AgileProductDesign.com
  28. 28. <ul><li>Easy to understand – Makes sense to the reader </li></ul><ul><li>A (software/system) requirement </li></ul><ul><li>One or two sentences with value to the customer </li></ul><ul><li>Written by the Customer – PO or BA </li></ul><ul><li>Refined by Development – Tasks and Technical </li></ul><ul><li>Negotiable – Conversation token </li></ul><ul><li>Small and estimable – Small enough to estimate </li></ul><ul><li>Testable – Should have acceptance criteria </li></ul><ul><li>Becomes more detailed over time – Iteration Planning </li></ul>White Barrel LLC © 2010 Peter Saddington A User Story Is
  29. 29. White Barrel LLC © 2010 Peter Saddington User Story Process Step #1 Step #2 Step #3
  30. 30. <ul><li>Define the user personas! </li></ul><ul><li>What different types of customers/consumers interact with the system? </li></ul><ul><li>What are their roles? </li></ul>White Barrel LLC © 2010 Peter Saddington Step #1 - Where do we start?
  31. 31. <ul><li>User Roles </li></ul><ul><ul><li>Various types of user personas </li></ul></ul><ul><li>Role Modeling </li></ul><ul><ul><li>Brain storming </li></ul></ul><ul><ul><li>Organizing </li></ul></ul><ul><ul><li>Consolidating </li></ul></ul><ul><ul><li>Refining </li></ul></ul><ul><li>Extreme Characters? </li></ul>White Barrel LLC © 2010 Peter Saddington User Role Modeling
  32. 32. <ul><li>Scenario : You need to create a simple login and preferences mechanism for your corporate Twitter account </li></ul><ul><li>Who are your users of this system? </li></ul><ul><li>What are their roles? </li></ul>White Barrel LLC © 2010 Peter Saddington Exercise - Defining the Personas
  33. 33. White Barrel LLC © 2010 Peter Saddington Persona Definition Documentation?
  34. 34. Roadmap White Barrel LLC © 2010 Peter Saddington
  35. 35. Story Creation - Guidelines <ul><li>Stakeholders write user stories </li></ul><ul><li>Remember non-functional requirements </li></ul><ul><li>Indicate the estimated size </li></ul><ul><li>Indicate the priority </li></ul><ul><li>Include a unique identifier (if applicable) </li></ul><ul><li>Go into a product backlog </li></ul><ul><li>The product backlog is prioritized by value – Highest to lowest </li></ul>White Barrel LLC © 2010 Peter Saddington
  36. 36. Non-Functional Requirements <ul><li>Non-functional requirements should often be considered “constraints” on a system </li></ul><ul><li>Can include: </li></ul><ul><ul><li>Performance </li></ul></ul><ul><ul><li>Quality </li></ul></ul><ul><ul><li>Accuracy </li></ul></ul><ul><ul><li>Portability </li></ul></ul><ul><ul><li>Reusability </li></ul></ul><ul><ul><li>Maintainability </li></ul></ul><ul><ul><li>Interoperability </li></ul></ul><ul><ul><li>Capacity </li></ul></ul>White Barrel LLC © 2010 Peter Saddington Adapted from Mike Cohn www.mountaingoatsoftware.com
  37. 37. INVEST Model <ul><li>I ndependent – One user story should be independent of another (as much as possible). Dependencies between stories make planning, prioritization, and estimation much more difficult. </li></ul><ul><li>N egotiable – Details of the story can be worked out during an Iteration planning meeting. A story with too much detail can limit conversations (at times). </li></ul><ul><li>V aluable – Value to the customer. </li></ul><ul><li>E stimable – There needs to be enough detail for the developers to estimate a user story to allow prioritization and planning of the story. </li></ul><ul><li>S mall – A good story should be small in effort, typically no more than 2-3 person weeks of effort (smaller is better)! </li></ul><ul><li>T estable – User stories should be testable with certain acceptance criteria. Saying something like “software should be easy to use” is not helpful. </li></ul>White Barrel LLC © 2010 Peter Saddington Bill Wake’s INVEST Model
  38. 38. Ron Jeffries 3 C’s <ul><li>Card – Stories written on note cards with annotations as needed (estimates, notes, etc) </li></ul><ul><li>Conversation – Details behind story come out through conversations with the Product Owner </li></ul><ul><li>Confirmation – Acceptance tests confirm the story was coded correctly </li></ul>White Barrel LLC © 2010 Peter Saddington
  39. 39. Four Main Components of a Story <ul><li>( Given ( AS A ) ) – “As a business owner…” / “Given a new list…” </li></ul><ul><li>( When ( I WANT ) ) – “I’d like the ability to…” / “We need a function to…” / “When a customer clicks on…” / “When a dropdown opens…” </li></ul><ul><li>( Then ( SO THAT ) ) – “So that I can…” / “So that the customer can…” / “Then the customer should see…” / “Then the dropdown list should…” </li></ul><ul><li>( Acceptance Criteria ) – Verifiable and testable criteria that can be tested based on THEN clause. </li></ul><ul><li>Or Simply: “As a <user type>, I want to <function> so that I can <business value> </li></ul>White Barrel LLC © 2010 Peter Saddington
  40. 40. 1. Given <ul><li>( Given ( AS A ) ) – “As a business owner…” / “Given a new list…” </li></ul><ul><li>We want users to be tangible with needs </li></ul><ul><li>Build out “Personas” or “User Roles” – Standard user definitions (Sacred – Added with purpose) </li></ul><ul><li>Avoid generic terms </li></ul>White Barrel LLC © 2010 Peter Saddington
  41. 41. 2. When <ul><li>( When ( I WANT ) ) – “I’d like the ability to…” / “We need a function to…” / “When a customer clicks on…” / “When a dropdown opens…” </li></ul><ul><li>This is the meat and potatoes of the story </li></ul><ul><li>This is where you describe the functions </li></ul>White Barrel LLC © 2010 Peter Saddington
  42. 42. 3. Then <ul><li>( Then ( SO THAT ) ) – “So that I can…” / “So that the customer can…” / “Then the customer should see…” / “Then the dropdown list should…” </li></ul><ul><li>This is to show the intrinsic value of the story </li></ul><ul><li>The value is to the persona, user, or author </li></ul>White Barrel LLC © 2010 Peter Saddington
  43. 43. 4. Acceptance Criteria <ul><li>( Acceptance Criteria ) – Verifiable and testable criteria that can be tested based on THEN clause. </li></ul><ul><li>These are essentially tests – Conditions of satisfaction </li></ul><ul><li>Example: As a user, I can cancel a reservation. </li></ul><ul><ul><li>Verify that a premium member can cancel </li></ul></ul><ul><ul><li>Verify that a email confirmation is sent </li></ul></ul><ul><ul><li>Verify that the hotel is notified of any cancelation </li></ul></ul><ul><li>These acceptance criteria can become developer tasks </li></ul>White Barrel LLC © 2010 Peter Saddington
  44. 44. 4a. Acceptance Stories <ul><li>( Acceptance Stories ) – Verifiable and testable criteria written in acceptance test form. </li></ul><ul><li>Scenario 1: TITLE </li></ul><ul><ul><li>GIVEN [context] </li></ul></ul><ul><ul><li>And [some more context] </li></ul></ul><ul><ul><li>When [event] </li></ul></ul><ul><ul><li>Then [outcome] </li></ul></ul><ul><ul><li>And [another outcome] </li></ul></ul>White Barrel LLC © 2010 Peter Saddington
  45. 45. 4b. Acceptance Confirmation <ul><li>( Acceptance Confirmation ) – Verifiable and testable criteria written in “Success” and “Failure” terms </li></ul><ul><li>Success – valid user logged in </li></ul><ul><ul><li>“ Remember my user name” selected – store cookie / automatic login next time </li></ul></ul><ul><ul><li>“ Remember my user name” not selected – force login next time </li></ul></ul><ul><li>Failure – display message: </li></ul><ul><ul><li>“ Email address in wrong format” </li></ul></ul><ul><ul><li>“ Incorrect password, please try again” </li></ul></ul><ul><ul><li>“ Service unavailable, please try again” </li></ul></ul><ul><ul><li>Etc. </li></ul></ul>White Barrel LLC © 2010 Peter Saddington
  46. 46. Exercise – 99 Balloons <ul><li>Let’s form some teams! </li></ul><ul><li>Round 1 </li></ul><ul><li>Recreate my balloon with: 2 round eyes, a triangle nose, and a semi-circle mouth </li></ul><ul><li>2 minutes! Go! </li></ul><ul><li>Round 2 </li></ul><ul><li>How can you improve for the next iteration? </li></ul><ul><li>Round 3 </li></ul><ul><li>How did you change how you worked this time around? </li></ul>White Barrel LLC. © 2011 Peter Saddington
  47. 47. <ul><li>User Interviews </li></ul><ul><ul><li>Select right interviewees </li></ul></ul><ul><ul><li>Ask open-ended, context-free questions </li></ul></ul><ul><li>Questionnaires </li></ul><ul><ul><li>Larger population of users </li></ul></ul><ul><ul><li>When you need specific answers to questions </li></ul></ul><ul><li>Observation </li></ul><ul><ul><li>Best for in-house developments </li></ul></ul><ul><li>Story writing workshops </li></ul>White Barrel LLC © 2010 Peter Saddington Step #2 – Gathering User Stories
  48. 48. <ul><li>Scenario : You need to create a simple login and preferences mechanism for your corporate Twitter account </li></ul><ul><li>We’ve determined our users… </li></ul><ul><li>Let’s refine the set of user stories </li></ul>White Barrel LLC © 2010 Peter Saddington Exercise – Refine the User Stories
  49. 49. Roadmap White Barrel LLC © 2010 Peter Saddington
  50. 50. Product Backlog to Release Backlog <ul><li>A prioritized list of features for the given product </li></ul><ul><li>Stories are implemented based on their priority </li></ul><ul><li>The TOP priority Features are put into iterations first </li></ul><ul><li>Changes to the iterations are OK </li></ul><ul><li>After stories are built they go into a release backlog </li></ul>White Barrel LLC. © 2010 Peter Saddington
  51. 51. Prioritization Factors to Consider <ul><li>Financial value of features </li></ul><ul><li>Costs of implementation </li></ul><ul><li>Amount of risk removed / added </li></ul><ul><li>Training on new features </li></ul><ul><li>PO should be enabled </li></ul>White Barrel LLC. © 2010 Peter Saddington
  52. 52. MoSCoW Method <ul><li>M – MUST have (Critical for success) </li></ul><ul><li>S – SHOULD have if possible (If not time critical) </li></ul><ul><li>C – COULD have if it does not affect anything else (Include if little development cost) </li></ul><ul><li>W – WON’T have this time, but WOULD like in future </li></ul>White Barrel LLC © 2010 Peter Saddington MoSCoW method - Dai Clegg of Oracle UK for DSDM
  53. 53. M & S of MoSCoW <ul><li>M – MUST have (Critical for success) </li></ul><ul><ul><li>Essential - key stakeholders needs will not be satisfied if this requirement is not delivered and the timebox will be considered to have failed </li></ul></ul><ul><li>S – SHOULD have if possible (If not time critical) </li></ul><ul><ul><li>Important - but if not delivered within the current timebox, there is an acceptable workaround until it is delivered during the next sprint </li></ul></ul>White Barrel LLC © 2010 Peter Saddington
  54. 54. C & W of MoSCoW <ul><li>C – COULD have if it does not affect anything else (Include if little development cost) </li></ul><ul><ul><li>“ Nice to have” – this is estimated to be possible to complete in the timebox but will be de-scoped if an underestimation has occured </li></ul></ul><ul><li>W – WON’T have this time, but WOULD like in future </li></ul><ul><ul><li>Will not be delivered within the timebox </li></ul></ul>White Barrel LLC © 2010 Peter Saddington
  55. 55. Kano’s Model of Quality <ul><li>Objective and Subjective Quality </li></ul><ul><li>Must-haves – Same as “M” in MoSCoW </li></ul><ul><li>One-dimensional – “The more of this I get, the better.” </li></ul><ul><li>Delighters – Great to haves </li></ul>White Barrel LLC © 2010 Peter Saddington Noriaki Kano – Theory of Product Development
  56. 56. Kano’s Model - Example <ul><li>In Agile – Objective quality is non-negotiable </li></ul><ul><li>Subjective quality – Perception of quality </li></ul><ul><ul><li>To accurately assess subjective quality, the Product Owner MUST know the customers (primary users) </li></ul></ul><ul><ul><li>One user’s “delighter” may leave others apathetic </li></ul></ul><ul><ul><li>One user’s “must have” is useless to others </li></ul></ul>White Barrel LLC © 2010 Peter Saddington Jeff Paton – www.Agileproductdesign.com
  57. 57. Prioritization Sliders White Barrel LLC. © 2010 Peter Saddington
  58. 58. <ul><li>Manage the backlog by: </li></ul><ul><ul><li>Sorting stories by user persona </li></ul></ul><ul><ul><li>Sorting stories by highest priority (value) </li></ul></ul><ul><ul><li>Review stories for completeness </li></ul></ul><ul><ul><li>Asking the 4 “WHYs” for business value </li></ul></ul><ul><ul><ul><li>Why do you want…? </li></ul></ul></ul><ul><ul><ul><ul><li>[As a] Customer Service Representative </li></ul></ul></ul></ul><ul><ul><ul><ul><li>[I want] to have a button </li></ul></ul></ul></ul><ul><ul><ul><ul><li>[So that] I can go to the next screen… </li></ul></ul></ul></ul>White Barrel LLC © 2010 Peter Saddington Step #3 – A.C. and Backlog Priority
  59. 59. <ul><li>Scenario : You need to create a simple login and preferences mechanism for your corporate Twitter account </li></ul><ul><li>We’ve determined our users… </li></ul><ul><li>We’ve refined the set of user stories </li></ul><ul><li>Let’s put A.C. and priority </li></ul>White Barrel LLC © 2010 Peter Saddington Exercise – Stories to Backlog
  60. 60. Roadmap White Barrel LLC © 2010 Peter Saddington
  61. 61. Themes to Tasks White Barrel LLC © 2010 Peter Saddington
  62. 62. Tasks Warm Up Exercise <ul><li>What are all the things you did to get ready to be at work today? </li></ul><ul><li>Starting from the moment you woke up to arriving here. </li></ul><ul><li>Take a sheet of paper and write them down! </li></ul>White Barrel LLC © 2010 Peter Saddington
  63. 63. Tasks vs Tools Exercise <ul><li>Share with the group some example lists </li></ul><ul><li>What are common themes and tasks? </li></ul><ul><li>What was different? </li></ul>White Barrel LLC © 2010 Peter Saddington
  64. 64. Goals, Tasks, Tools White Barrel LLC © 2010 Peter Saddington
  65. 65. User Stories are Tasks or Tools White Barrel LLC © 2010 Peter Saddington
  66. 66. Stories Satisfy User NEEDS First! White Barrel LLC © 2010 Peter Saddington
  67. 67. <ul><li>Start with specific personas </li></ul><ul><li>Write closed stories first </li></ul><ul><li>Write stories collaboratively </li></ul>White Barrel LLC © 2010 Peter Saddington Simple Guidelines for Good Stories
  68. 68. Exercise – Creating at a Story <ul><li>Ta ke a current feature your team is aware of </li></ul><ul><li>Each team member writes the story </li></ul><ul><li>Share </li></ul><ul><li>Discuss – Implications / Constraints / Missed AC </li></ul><ul><li>Review </li></ul>White Barrel LLC © 2010 Peter Saddington
  69. 69. Roadmap White Barrel LLC © 2010 Peter Saddington
  70. 70. Epic User Stories <ul><li>Causes for Story Size </li></ul><ul><li>Stories cover too much information </li></ul><ul><li>Story writers do not have the needed domain knowledge </li></ul><ul><li>Stories have uncertainty due to dependence on new technology </li></ul><ul><li>Story writers cannot articulate exactly what they want </li></ul>White Barrel LLC © 2010 Peter Saddington
  71. 71. Breaking Up Epics <ul><li>Split – Slice stories up into different scenarios </li></ul><ul><li>Spike – Too many unknowns? Time-box a spike and take a deep dive into the technology or domain </li></ul><ul><li>Stub – Part of a story known and part unknown. Fake it with a stub! Work on the known part up till the unknown. </li></ul><ul><li>Time box – The PO knows they need something, but until they get it, not sure if it’s right </li></ul>White Barrel LLC © 2010 Peter Saddington
  72. 72. Splitting for Value - Three Rules <ul><li>When breaking down epics, remember: </li></ul><ul><li>Split stories for value – No value? Hard to prioritize </li></ul><ul><li>Split a story that gets you more equally sized small stories </li></ul><ul><li>Split an epic that lets you deprioritize or throw away a story </li></ul>White Barrel LLC © 2010 Peter Saddington
  73. 73. Exercise – Breaking Up Epics <ul><li>Let’s take an example from our existing backlog </li></ul>White Barrel LLC © 2010 Peter Saddington
  74. 74. Suggestions for Splitting Up Epics <ul><li>Handle empty scenarios and core functions first </li></ul><ul><li>Happy path, then alternate flows / exceptions </li></ul><ul><li>Single option, then add additional options </li></ul><ul><li>Simple (or no) UI, then add bells / whistles </li></ul><ul><li>Transient case (no memory between sessions) before persistence </li></ul><ul><li>Static elements, then dynamic based on content </li></ul><ul><li>User specified, then more automation </li></ul>White Barrel LLC © 2010 Peter Saddington
  75. 75. Roadmap White Barrel LLC © 2010 Peter Saddington
  76. 76. Notes on Bug or Issue Tracking <ul><li>Steps to Reproduce / Recreate the Bug </li></ul><ul><li>Actual Results </li></ul><ul><li>Expected Results </li></ul><ul><li>Any other details as appropriate </li></ul>White Barrel LLC © 2010 Peter Saddington
  77. 77. Exercise – Baseline Story Estimation <ul><li>Different Stories in different sizes (1,2,3,5,8…) </li></ul><ul><li>What was the estimated size? </li></ul><ul><li>What were the complexities of that story? </li></ul><ul><li>Does this story need a re-write? What was missed? </li></ul><ul><li>Complete for sizes </li></ul>White Barrel LLC © 2010 Peter Saddington
  78. 78. Questions? White Barrel LLC © 2010 Peter Saddington

×