Download as PDF, PPTX
Uploaded bySally Elatta
What is 'Just Enough' Documentation in Agile?
The document presents a session by Sally Elatta on 'just enough documentation' in Agile methodology, outlining the key characteristics of agile and traditional requirements, the importance of backlog hierarchy, and the concept of estimation during the Agile lifecycle. It emphasizes that agile prioritizes flexibility and lightweight documentation, encouraging teams to focus on delivering value through clear requirements and collaboration. The session offers insights on effectively managing change and tracking progress while ensuring that documentation serves immediate goals without being overly detailed.
In this document
Powered by AI
Introduction to ‘Just Enough Documentation’ in Agile; speaker background and session goals.
Comparison of characteristics between traditional and Agile requirements.
Overview of the Agile lifecycle and importance of 'Just Enough' discussions in release planning.
Explanation of what a story is in Agile, with sample stories emphasizing business value.
Introduction to backlog hierarchy and the necessity of including non-functional stories.
Examples of foundation stories needed to ensure a successful initial iteration.
Agile approach to estimation, emphasizing relative complexity and 'Just Enough' discussions.
Samples of release backlog and release planning practices.
Details that ensure a solid foundation during iteration 0, including high-level documentation.
Focus on defining what constitutes 'Done' in development iterations.
Sample test cases and business rules to illustrate the testing aspect of Agile.
Examples of documentation from sampled test results to activity diagrams.
Understanding Agile traceability matrix as a tool for managing project requirements.
Strategies for managing changes and tracking progress in Agile.
Summary of what 'Just Enough' documentation entails and its value in Agile.
Overview of training and consulting services related to Agile offered by Sally Elatta.
References for further reading and contact information for inquiries.
More Related Content
Similar to What is 'Just Enough' Documentation in Agile?
What is 'Just Enough' Documentation in Agile?
- 1. What is ‘JustEnough Documentation’ in Agile? Presenter: Sally Elatta 1
- 2. About the Speaker •Sally Elatta • Founder of AgileTransformation.com • Enterprise Process Improvement Coach, Architect, Trainer • Coached over 18 teams on adopting Agile methods. • Taught over 600+ students on Agile • Certified ScrumMaster, Scrum Practitioner, IBM, Sun, and Microsoft Certifications. • Sally@AgileTransformation.com • 402 212-3211 2 Copyright(c) Sally Elatta 2009 www.AgileTransformation.com
- 3. Session Goals • Review of our last session • The Agile view on requirements • Reviewing what is ‘Just Enough’ for each Agile phase • Sample requirements • Resources 3 Copyright(c) Sally Elatta 2009 www.AgileTransformation.com
- 4. Traditional Requirements Characteristics 4 Copyright(c) Sally Elatta 2009 www.AgileTransformation.com
- 5. Agile Requirements Characteristics 5 Copyright(c) Sally Elatta 2009 www.AgileTransformation.com
- 6. The Agile Lifecycle– Big Picture
- 7. During Release Planning – Breakdown requirements into stories – Need ‘Just Enough’ Discussions to breakdown a story – Build a complete backlog – Need ‘Just Enough’ Discussions to identify all stories – Prioritize based on value and dependency – ‘Just Enough’ related to priority – Estimate/Size each story – ‘Just Enough’ to estimate a story (*) – Build the Release Plan 7 Copyright(c) Sally Elatta 2009 www.AgileTransformation.com
- 8. What is aStory? • A small piece of Follows these attributes: requirement that is ‘valuable’ to the Understandable business. Independent Negotiable Story Format: Valuable “As a <role>, I want Estimatable Small to <goal>, so I can Testable <value>”
- 9. Sample Stories As an Agent I As an Agent I want view the want to enter ‘Current Leads’ new lead report. information so I can track them. As a BA I want to define the existing product return process so As the XYZ system I can identify any I want to receive inefficiencies. As the EDW System, I want to new member have ABC file enrollments each loaded on a night so I can schedule. process them.
- 10. Sample Use CaseDiagram 10 Copyright(c) Sally Elatta 2009 www.AgileTransformation.com
- 11. The Backlog Hierarchy Business Domain Theme/Feature/Epic Feature2 Story1 Story2 Story3 11 Copyright(c) Sally Elatta 2009 www.AgileTransformation.com
- 12. Non Functional/ Foundational Stories • Your backlog is not ‘Complete’ without identifying and planning for non-functional system stories. • Typically scheduled for iteration 0 or sprinkled throughout other iterations. • Identified by the team (DBA, Security, Infrastructure, Architect, Developers ..etc) • Iteration 0 needs to complete ‘Just Enough’ foundation stories for iteration 1 to be successful. 12 Copyright(c) Sally Elatta 2009 www.AgileTransformation.com
- 13. Sample Foundation Stories Develop High Setup and Level Service configure XYZ Architecture Test Server Diagram Develop High Level Process Diagram for the ‘Get a Quote’ Setup ABC process. Setup and Database. Configure LDAP Build Logical Design Model.
- 14. Story Points • Wesimply use relative complexity buckets to size each story. 20+ Smallest Small Medium Med-large Large Very Large EPIC! How many stories a team gets ‘Done’ each iteration is their Velocity Copyright(c) Sally Elatta 2009 14 www.AgileTransformation.com
- 15. Agile View onEstimates • Looking for relatively good estimates instead of precisely accurate ones. • Done by the team who will actually do the work. • Updated throughout the project. • Measure stories in relative complexity points. • Measure tasks in hours. • Measure ‘Velocity’ from actual team performance. • Estimate in detail near term efforts, plan higher level for following ones. 15 Copyright(c) Sally Elatta 2009 www.AgileTransformation.com
- 16. ‘Just Enough’ to Estimate a Story • Need ‘Just Enough’ discussion to estimate the story’s complexity. • Do not need to know detailed business rules and exact solution implementation details. • ‘Just Enough’ is reached when the team can size the story. Let’s explore the sample guide 16 Copyright(c) Sally Elatta 2009 www.AgileTransformation.com
- 17. Sample Release Backlog 17 Copyright(c) Sally Elatta 2009 www.AgileTransformation.com
- 18. Sample Release Plan View Sample Release Plan 18 Copyright(c) Sally Elatta 2009 www.AgileTransformation.com
- 19. During Iteration 0 • ‘Just Enough’ for iteration 0 could include: – High level architecture diagrams – High level business process diagrams – High level data logical diagrams – Look and Feel Template – System straw-man – What else? 19 Copyright(c) Sally Elatta 2009 www.AgileTransformation.com
- 20. Sample Business Process Diagrams 20 Copyright(c) Sally Elatta 2009 www.AgileTransformation.com
- 21. During Development Iterations • Now come the details! • Team must first define what makes a story ‘Done’ • Then we can decide on what is ‘Just Enough’ to get us there. 21 Copyright(c) Sally Elatta 2009 www.AgileTransformation.com
- 22. Sample Definition of‘Done’ • Story Level: – All unit tests have passed. – Code review is complete and code is checked in to source control. – UI Branding has been applied. – All acceptance test cases have passed in the test environment. – No outstanding bugs exists for this story. 22 Copyright(c) Sally Elatta 2009 www.AgileTransformation.com
- 23. Sample User TestCases “A customer can pay for shopping cart items using a credit card” Test with VISA, MasterCard and American Express (pass) Test with Diner’s Club (fail) Test with bad and missing 3 digit codes (fail) Test with expired cards (fail) Test with a purchase amount over the card limit (fail) 23 Copyright(c) Sally Elatta 2009 www.AgileTransformation.com
- 24. Sample Business Rules • 1.1-TC1 ‘Verify that student eligibility rules are applied correctly during registration’ – TC1-BR1: Students with a ‘hold’ record cannot register on the site. – TC1-BR2: Students with outstanding payment from last semester cannot register. – TC1-BR3: Student already registered cannot register again. 24 Copyright(c) Sally Elatta 2009 www.AgileTransformation.com
- 25. Sample Test Results 25 Copyright(c) Sally Elatta 2009 www.AgileTransformation.com
- 26. Sample UI Prototypes 26 Copyright(c) Sally Elatta 2009 www.AgileTransformation.com
- 27. Sample Activity Diagram 27 Copyright(c) Sally Elatta 2009 www.AgileTransformation.com
- 28. The Wonderful ‘Traceability’ Question • Here is an Agile traceability matrix: > 1 - Feature > 1.1 Story >1.1 – TC1 Test Cases > TC1-BR1 Business Rules >BR1-T001 Test Scenario Results >Tasks >Code 28 Copyright(c) Sally Elatta 2009 www.AgileTransformation.com
- 29. Managing Change 29 Copyright(c) Sally Elatta 2009 www.AgileTransformation.com
- 30. Tracking Progress 30 Copyright(c) Sally Elatta 2009 www.AgileTransformation.com
- 31. Summary • To know what is ‘Just Enough’ you need to know what your immediate next goal is. • Agile invests cautiously on detailed requirements by doing it just-in-time so it can stay flexible to requirements change. • ‘Just Enough’ does not equal ‘Not Good Enough’! • Agile encourages lightweight easy to understand and maintain documentation. 31 Copyright(c) Sally Elatta 2009 www.AgileTransformation.com
- 32. How We CanHelp Training Coaching & Consulting • Executive and Business • Troubled Project Overview of Agile/Lean Assessment & • Real World Agile and Recovery Scrum team training + • Agile Project Initiation Project Jump Start and Planning • Effective Facilitation & • End to End Project Requirements Gathering Execution • Servant Leadership • Organizational • SOA Assessments • … More! • Process Improvement Roadmap Execution
- 33. This Seminar forYOUR Company Contact me if you’re interested in this seminar for your own organization. Either in person or over the web. It could be FREE if you qualify
- 34. Resources • www.AgileModeling.com • http://www.agilemodeling.com/essays /agileRequirementsBestPractices.htm • Questions? Sally@AgileTransformation.com 34