O slideshow foi denunciado.
Utilizamos seu perfil e dados de atividades no LinkedIn para personalizar e exibir anúncios mais relevantes. Altere suas preferências de anúncios quando desejar.

[Srijan Wednesday Webinar] How to create an Effective Documentation Framework for Your Agile Project

150 visualizações

Publicada em

How much documentation is enough documentation in an Agile project?

Agile Scrum outlines a set of artifacts that help efficiently develop, track progress and deliver projects - the product backlog, sprint backlog, sprint burndown chart and increment. However, on-the-ground there is often a constant struggle to balance the iterative nature of an Agile project, with the stakeholder’s requirement for documentation that they understand.

Join the webinar to find out how to make sure you are documenting your work, without overwhelming the entire team.

Key Takeaways

- Understand how to create great Scrum documentation artifacts
- Explore the documentation framework for an IT project that uses Scrum
- Learn industry-standard documentation formats

View all webinars at: https://www.srijan.net/webinar

Publicada em: Software
  • Seja o primeiro a comentar

  • Seja a primeira pessoa a gostar disto

[Srijan Wednesday Webinar] How to create an Effective Documentation Framework for Your Agile Project

  1. 1. AGENDA ● What are Scrum Artifacts? ● Elements of any documentation in Agile ○ Simple ○ Sufficient ○ Sustainable ● Best practices while creating a document ○ Static documentation vs “Living documentation” ○ Idea-based vs Experience-based ○ Actions vs Features ● How much documentation do I need?
  2. 2. TAKEAWAYS ● Understand the elements of a useful Scrum documentation artifact ● Identify the documentation ideal for your project
  3. 3. SCRUM ARTIFACTS “A Scrum Artifact is a tool created by a member of the Scrum team, or by an individual stakeholder to solve a certain business problem” PURPOSE Scrum's artifacts represent work or value to maximize transparency of key information so that everybody has the same understanding of the requirements.
  4. 4. SCRUM ARTIFACTS A list of all work to be done in a project, organized by priority Product Backlog ● A living document that is updated throughout the project ● Owned by PO/BA ● TA - Client/Business Work selected by team to complete in a Sprint Sprint Backlog ● Defined by the Sprint goal set by PO ● Detailing done up to task level ● Owned by team ● TA - Dev team For project monitoring and tracking Burndown Charts + RAID ● Track Sprints ● Track Epics ● Track Impediments ● Owned by SM ● TA - Delivery team Sum of all product backlog items that are usable at the end of a Sprint Product Increment ● Meets the Definition-of-Done ● Handed over to client/PO to release ● Owned by SM + team ● TA - PO, Client/Business
  5. 5. ELEMENTS OF ANY DOCUMENTATION IN AGILE SUFFICIENT SIMPLE SUSTAINABLE
  6. 6. ELEMENTS ... - SIMPLE “The best documentation is the simplest that gets the job done.” vs
  7. 7. ELEMENTS ... - SUFFICIENT Document only that which is required for the stakeholder to understand the item in question. vs Mockup credit - Grafix Artist Screen Name App Landing Screen (first time) Trigger Displayed the first time the app is launched Features Screen is split into 2 Sections - ● Introduction Messages - Contains 3 Introduction Messages - Every message contains a Title and Description - User can move to next message using an arrow or swipe - User has an option to Skip Introduction Messages ● Sign In - User can Sign In via Email, OR - User can Sign In via Facebook
  8. 8. ELEMENTS ... - SUSTAINABLE ● A sustainable document in Agile means - ○ It is a “living” document ○ Should be structured such that it can be updated regularly with every iteration ○ Do not overlap content within documents - so you update in only one place and there is no lack of consistency ● Example - A Software Space in Confluence - ○ Snapshot of Product Requirements - links out to Epics and Stories on JIRA backlog ○ RAID Log + Meeting Notes ○ Product Increments + Question Log ○ Filelists - Data and Content
  9. 9. ELEMENTS ... - SUSTAINABLE
  10. 10. ELEMENTS ... - SUSTAINABLE
  11. 11. BEST PRACTICES WHILE CREATING DOCUMENTS
  12. 12. “LIVING DOCUMENT” vs STATIC ● Static document ○ A document capturing functional requirements, non-functional requirements, architecture and designs (UI/UX) ○ Becomes the “Bible” for the Development and Delivery stages ● “Living” document ○ A document capturing actions and their acceptances, and updated with every iteration ○ Fulfils the 3 S’s - Simple, Sufficient, Sustainable ● Examples of static documents - ○ High-level requirements specification, detailed requirements specification, design documents ● Examples of “living” documents - ○ Product backlog, prototypes, RAID log, product increment
  13. 13. EXPERIENCE-BASED vs IDEA-BASED
  14. 14. ACTIONS vs FEATURES “As a Buyer, I should be able to filter products by Categories, so that I can view a list of Products within that category” Action E-commerce use case Requirement View Products by Category This use case describes how a buyer can filter products on a Product Listing Page by categories. The buyer will can see a listing view of products, along with a Categories filter at the top (ref: UI/UX document). He can select a particular category to filter the products. The page will refresh based on the buyer’s selection. Non-functional requirements - Ref: Architecture document, Non-Functional requirements document Feature
  15. 15. PRODUCT BACKLOG - A USER STORY ACCEPTANCE CRITERIA NON-FUNCTIONAL REQUIREMENTS ASSUMPTIONS DEPENDENCIES TESTING STEPS STORIES are Specifiable, and Implementable, and Estimable, and Verifiable Each function listed separately LIVING EXPERIENCE-BASED ACTION-BASED
  16. 16. HOW MUCH DO I NEED? 1 BUSINESSGOALS DiscoveryW orkbook-Product Requirem ents+ Prototypes 2 FEATURES ProductBacklog-Functional, Non-functional ProductIncrem ent 3 FUNCTIONS SprintBacklog-Dependencies, Assum ptions 4 TASKS Burndow n Charts RAID Log M eetingNotes STRATEGY VALUE CAPABILITY WORK
  17. 17. KEY POINTS TO NOTE ● Iterate, and then iterate some more ● Documentation needs time. Make documentation a part of your backlog and capacity estimation ● NEVER create a document without ○ An Owner ○ A Target Audience (TA) But, make all documentation available to all - Remember “Transparency” ● Adapt to suit your project needs

×