Scrum club progressiveelaboration-bobvincent

1,277 views
1,195 views

Published on

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

  • Be the first to like this

No Downloads
Views
Total views
1,277
On SlideShare
0
From Embeds
0
Number of Embeds
2
Actions
Shares
0
Downloads
10
Comments
0
Likes
0
Embeds 0
No embeds

No notes for slide
  • notes...
  • -may also have UI mockups/Prototypes/User research & other artifacts leading into release. -time for Qualitative research: discover unmet needs
  • Rank the backlog - just enough to meet objectives (release date, MMF)
  • Sprint / Iteration / Rolling-wave Planning (V1 experimentation)
  • define Done
  • -PO may have ATs coming in; create more in planning -GWT format forces ATs to be broken-down somewhat consistently -too many ATs in a story is a smell that the story is too large
  • Dev + PO + [Designers].
  • define behavior (solution specific) before code - think thru for better design write more efficient code
  • focusing on behavior rather than state = less brittle -difficult to predict what comes out of emergent design / expensive to try
  • May expose new ATs. too many==smell
  • Opportunity for more user testing (task testing) PO verifies ATs - proclaims DONE.
  • May expose opportunities for improvement (new stories). Identify features with high risk of iteration & rank them high.
  • automating all this
  • cucumber + rspec
  • Scrum club progressiveelaboration-bobvincent

    1. 1. Progressive Elaboration & Specification <ul><li>part 3 </li></ul><ul><li>Agile Analysis & Design The Trilogy </li></ul>
    2. 2. Bob Vincent <ul><li>Product Manager </li></ul><ul><li>XP, Scrum, Lean software projects since 2004 </li></ul><ul><li>CSPO, CSM </li></ul>
    3. 3. Progressive Elaboration &quot;Because of the potential for change, the project management plan is iterative and goes through progressive elaboration throughout the project's life cycle. Progressive elaboration involves continuously improving and detailing a plan as more-detailed and specific information and more accurate estimates become available .&quot;
    4. 5. Backlog Epics Stories
    5. 6. <ul><li>Describes an objective & motivation </li></ul><ul><li>Does NOT describe the solution </li></ul><ul><li>It’s pretty brief - “a promise for a conversation” </li></ul>Agile Stories
    6. 7. Story Title <ul><li>In order to [provide value] </li></ul><ul><li>[persona(s)] </li></ul><ul><li>want [a feature] </li></ul>
    7. 10. Acceptance Test-Driven Planning <ul><li>Process Agnostic </li></ul><ul><li>Participants: </li></ul><ul><ul><ul><ul><li>Product Owner </li></ul></ul></ul></ul><ul><ul><ul><ul><li>Testers </li></ul></ul></ul></ul><ul><ul><ul><ul><li>Devs </li></ul></ul></ul></ul><ul><ul><ul><ul><li>UX </li></ul></ul></ul></ul>Defining DONE
    8. 11. Acceptance Test-Driven Planning GIVEN [an initial context or condition] WHEN [persona] [does something] THEN [expected behavior occurs]
    9. 13. Behavior/Test-Driven Development <ul><li>Process Agnostic </li></ul><ul><li>Participants: </li></ul><ul><ul><ul><ul><li>Testers </li></ul></ul></ul></ul><ul><ul><ul><ul><li>Devs </li></ul></ul></ul></ul><ul><ul><ul><ul><li>UX </li></ul></ul></ul></ul>
    10. 14. Behavior/Test-Driven Development <ul><li>Specify behavior (test) before writing code </li></ul><ul><li>Test all the time </li></ul><ul><li>Refactor </li></ul><ul><li>Design all the time </li></ul><ul><li>Code design needs to flex & grow </li></ul><ul><li>Add spec/tests for new emergent behavior </li></ul>
    11. 15. User testing <ul><li>Usability testing goals: </li></ul><ul><li>Effectiveness </li></ul><ul><li>Efficiency </li></ul><ul><li>Satisfaction </li></ul>A B
    12. 17. Task
    13. 18. “ An interactive session with working software is worth a thousand meetings.”
    14. 19. Backlog Epics Stories ++
    15. 23. Thank You!

    ×