Agile's Just In Time Requirements

1,954 views
1,709 views

Published on

While the Agile Manifesto’s values clearly state they prefer working software over comprehensive documentation, the general misconception around Agile projects is that you don’t do any documentation. This session will cover what we truly mean by just-in-time requirements by discussing when to get details around requirements, best practices for storing/maintaining requirements, and how much detail is too little or too much. We will also cover other types of documentation such as design/architecture artifacts as well as end user documentation like help files/user guides and how they fit into an Agile process.

Published in: Technology, Business
0 Comments
4 Likes
Statistics
Notes
  • Be the first to comment

No Downloads
Views
Total views
1,954
On SlideShare
0
From Embeds
0
Number of Embeds
6
Actions
Shares
0
Downloads
0
Comments
0
Likes
4
Embeds 0
No embeds

No notes for slide

Agile's Just In Time Requirements

  1. 1. Agile's Just-In-Time Requirements: When, Where, and How Much Tommy Norman
  2. 2. Agenda • Introductions • Agile Documentation: Fact & Fiction • Why do we Document? • Documenting Agile Projects • Wrap Up
  3. 3. INTRODUCTIONS
  4. 4. Tommy Norman Senior Consultant Scrum Certified Microsoft MVP Agile Nashville TommyNorman.com @tommynorman
  5. 5. AGILE DOCUMENTATION Fact & Fiction
  6. 6. Agile Documentation
  7. 7. Agile Manifesto
  8. 8. Agile Manifesto
  9. 9. What’s wrong with documentation?
  10. 10. It grows stale and moldy…
  11. 11. Few people actually read it…
  12. 12. Written by only a few…
  13. 13. Sometimes it makes no sense…
  14. 14. So how does Agile handle that?
  15. 15. Just in time documentation…
  16. 16. The last responsible moment… Wait for it…
  17. 17. Document as you go…
  18. 18. WHY WE DOCUMENT
  19. 19. Why do we document?
  20. 20. Record what we plan to do…
  21. 21. Record what we actually did…
  22. 22. Pre versus Post documentation
  23. 23. What is the value of a document?
  24. 24. DOCUMENTING AGILE PROJECTS
  25. 25. User Stories
  26. 26. User Story Format As a I want so that
  27. 27. Conditions of Acceptance You complete me.
  28. 28. Qualities of a Good User Story Independent Negotiable Valuable Estimable Small Testable
  29. 29. When is a User Story enough?
  30. 30. Product Backlog 3 2 3 1 3 2 5 8 3 3 3 3 MoreDetail LessDetail
  31. 31. Product Backlog Grooming
  32. 32. The Last Responsible Moment… ReleaseSprint 1 Sprint 2 Sprint 3 Sprint 4 Sprint 5 As a role I want function so that benefit. Low 8
  33. 33. The Last Responsible Moment… ReleaseSprint 1 Sprint 2 Sprint 3 Sprint 4 Sprint 5 As a role I want function so that benefit.
  34. 34. The Last Responsible Moment… ReleaseSprint 1 Sprint 2 Sprint 3 Sprint 4 Sprint 5 As a role I want function so that benefit.
  35. 35. How much documentation? Regulation Team’s Domain Knowledge Team Distribution Availability of SMEs Criticality of the System
  36. 36. Where do I store documentation?
  37. 37. Pre Documentation
  38. 38. Pre Documentation Story Wall White Boards Flip Charts Agile Management Tools Online Repositories
  39. 39. Post Documentation The Code The Tests Dynamic Models Recorded Demos Documents
  40. 40. WRAP UP
  41. 41. Wrap Up Just in Time Requirements Document As You Go Groom Constantly Pre (Informal) Post (Less Informal) Is it Valuable?
  42. 42. THANK YOU!

×