SlideShare a Scribd company logo

Agile status reporting primer

•
•
S
Saugata Das, CSM, SA (SAFe 5)

This presentation details the essentials of Agile project progress report. This is a primer for Scrum Masters and Product Owners for providing the given essential details in their progress reports.

Related slideshows

Seminar on pert
Seminar on pertSeminar on pert
Seminar on pert
 
A guide to create a quality project schedule
A guide to create a quality project scheduleA guide to create a quality project schedule
A guide to create a quality project schedule
 
Javier Garcia - Verdugo Sanchez - Six Sigma Training - W1 Rifle Shot Studies
Javier Garcia - Verdugo Sanchez - Six Sigma Training - W1 Rifle Shot StudiesJavier Garcia - Verdugo Sanchez - Six Sigma Training - W1 Rifle Shot Studies
Javier Garcia - Verdugo Sanchez - Six Sigma Training - W1 Rifle Shot Studies
 
1 of 18
Download to read offline
Saugata Das Essentials of Agile Project Progress Reporting A Primer for Scrum Masters and Product Owners !1
Waterfall Model ❖ Has strict guidelines for reportage (which need to be followed in both spirit and letter) ❖ If an organization follows this model or its multiple variants such as Spiral model, V model etc., each department will need to have a status report regarding scope, cost, schedule, and quality. !2 Waterfall Model V Model
What and Why of Recurrent Progress Update ❖ Progress update requires recurrent status update of its 3 key identifiers – Scope, Cost, and Schedule. ❖ Other sub-attributes such as Quality, Risks, Defect, and Change request also need to be updated. ❖ Without verification of above information, Communication Management principles, as identified under the Waterfall model, cannot be satisfied. !3 Waterfall Model
Courtesy - Neon Rain via CC However, Agile processes, by definition, have a strong review process through a Sprint review ceremony. Why then should a separate status reporting be enabled for such projects?
When is Progress Report Important in Agile Projects? ❖ For complex projects involving team sizes in excess of 8 members ❖ For projects involving multiple geographically-dislocated sites and teams It is not important on a recurrent basis for simple Agile projects. !5 An example of a complex project environment:
Agile Outward Bound Artifacts Scrum Artifacts Following Artifacts are the key ingredients in any reportage of an Agile project: ❖ Product Backlog ❖ Sprint Backlog ❖ Sprint Increments Click here for further details. !6
Agile Metrics Below are some metrics which may or may not be required for reportage: ❖ Sprint Burndown – Tracks completion of work through Sprint against the forecast given by the team ❖ EPIC and Release Burndown ❖ Tracks completion of work over a larger set of PBIs ❖ Gives a view of progress towards the next release ❖ Tracks progress towards Epics spread out between multiple Sprints ❖ Velocity - Refers to the average amount of work completed within a Sprint, measured in terms of story points or hours. You can make a correct forecast through this metric. ❖ Cumulative Flow Diagram (CFD) – A key metric to identify WIP limit of a team and allow correct batch sizes to be estimated ❖ Additional metrics (Optional) ❖ Pre-release defect count – How many defects were caught before PBIs were released? ❖ Post-release defect count – How many defects were caught after PBIs were released? ❖ Defects per Sprint – How many defects were recorded per Sprint? ❖ Planned-to-Done ratio – How many PBIs were planned across Sprints and of them, what was the ratio at which they were released? !7
Agile status reporting primer
EPIC Burndown Chart This chart is used to determine when all EPICs identified for release will actually be closed based on current velocity !9 ❖ X axis - Sprint numbers ❖ Y axis - EPIC story points ❖ Dotted line - Trend line (Shows the general trajectory of the EPIC velocity) ❖ Solid line - Consumption of actual story points The point at which the trend line touches 0 is when the Project can be marked for RELEASE.
Sprint Burndown Chart Used for any project which started on Agile and needs to track how story points or hours are consumed !10 ❖ X axis - Sprint days ❖ Y axis - Story points remaining to be implemented in the Sprint ❖ Trend line - General guideline where the remaining story points become 0 ❖ Solid line - Current situation of the Sprint w.r.t story consumption Solid Line Trend Line
Burndown vs. Burnup ❖ The Burndown chart is a very handy tool for all Scrum Teams. Here is why: ❖ Provides a view of the progress to the team ❖ Shows when the team might be able to close all Sprint Backlog ❖ Provides the Velocity (Story Points/Sprint) which can be used for forecasting (using ‘Yesterday’s Weather’ mechanism) ❖ However, it does not answer these two pertinent questions: ❖ Was work added or was no work done? For instance, the example provided on Slide 10 between 2nd and 4th July does not give you an answer. ❖ How many story points are yet to be Validated? How many have not even been started? In the Sprint Burndown example on Slide 10, story points are clearly left to be completed on 12th July. The first question is answered by using a BURNUP chart. The second one though, is far more difficult and requires a CFD. !11
CFD ❖ Shows the way tasks are allocated to different process stages ❖ Created out of different colored bands representing different process groups. ❖ Visually represents the following: ❖ WIP - The amount of work the team handles at any given point of time (In the above example, it is the “In Progress” band on any given day.) ❖ Addition of task and its rate - Was task added and if so, by how much? (In the above example, its the increase in “Open” on 24th May and 07th July.) ❖ Task deletion - Was task deleted and if so, by how much? ❖ Sudden rise or fall in activities - Shows problematic areas or possible bottlenecks !12
Which Chart Should You Use? ❖ Depends on the project and audience ❖ Use a Burndown chart if: ❖ The project does not cause mid-project addition or removal of Backlog items. ❖ The project is for an audience, who are viewing the project progress on a regular basis. ❖ Use a Burnup chart or CFD if the project has multiple addition/ deletion of items mid-project. A CFD provides a lot more information w.r.t story point per process stage. This ,in turn, provides more transparency about team activities to all stakeholders. !13
Additional Metrics ❖ Number of defects found per Sprint which shows the effectiveness of the Scrum team (See the example on the right.) ❖ A Planned-To-Done ratio bar graph for long-term projects !14 0 5 10 15 20 25 30 35 40 Sprint 1 Sprint 2 Sprint 3 Sprint 4 Sprint 5 Sprint 6 Sprint 7 Sprint 8 Sprint 9 Total Total
Impediment Backlog ❖ Created through the Impediments faced by the team during Sprint ❖ Its resolution might arrive during the Sprint, where it can be absorbed. ❖ Alternatively, the resolution can be made available for future Sprints, where it should be converted into a Backlog item. ❖ An impediment backlog is an essential part of any practical scrum progress report and needs to be made transparent to all. !15
Risk Assessment ❖ Risk assessment in an Agile world is best handled through ROAM methodology as given in Scaled Agile. ❖ This can also be used in simple Agile projects. ❖ This information is useful for stakeholders to see potential bottlenecks and react to them within the given timeframe. !16 Risk Item Id Details Resolved Owned Accepted Mitigated Action Action Holder S*_001 Full Product build for given product ID set needs to be available * Complete Production CI build setup to be completed by wk 2 Infra Scrum
Your Progress Report for Agile Project In a nutshell, here is a conclusion to the essentials of the progress report contents for your initial Agile projects: ❖ It should hold a simple view of the success and failure of the team. ❖ It should provide a snapshot of all the scrum artifacts (as given in slide 6). ❖ It should provide an EPIC Release Burndown chart as part of the above point. ❖ It should provide one of the charts mentioned in slides 10-12. ❖ It should provide the Impediment Backlog. ❖ It could provide additional optional metrics as defined on slide 14 ❖ It should provide details of Risk Assessment. !17
The End Profile – www.saugatadas.net Blog – www.saugatadas.net/blog LinkedIn – www.linkedin.com/in/withsaugata Email – saugatad@gmail.com

More Related Content

Agile status reporting primer

  • 1. Saugata Das Essentials of Agile Project Progress Reporting A Primer for Scrum Masters and Product Owners !1
  • 2. Waterfall Model ❖ Has strict guidelines for reportage (which need to be followed in both spirit and letter) ❖ If an organization follows this model or its multiple variants such as Spiral model, V model etc., each department will need to have a status report regarding scope, cost, schedule, and quality. !2 Waterfall Model V Model
  • 3. What and Why of Recurrent Progress Update ❖ Progress update requires recurrent status update of its 3 key identifiers – Scope, Cost, and Schedule. ❖ Other sub-attributes such as Quality, Risks, Defect, and Change request also need to be updated. ❖ Without verification of above information, Communication Management principles, as identified under the Waterfall model, cannot be satisfied. !3 Waterfall Model
  • 4. Courtesy - Neon Rain via CC However, Agile processes, by definition, have a strong review process through a Sprint review ceremony. Why then should a separate status reporting be enabled for such projects?
  • 5. When is Progress Report Important in Agile Projects? ❖ For complex projects involving team sizes in excess of 8 members ❖ For projects involving multiple geographically-dislocated sites and teams It is not important on a recurrent basis for simple Agile projects. !5 An example of a complex project environment:
  • 6. Agile Outward Bound Artifacts Scrum Artifacts Following Artifacts are the key ingredients in any reportage of an Agile project: ❖ Product Backlog ❖ Sprint Backlog ❖ Sprint Increments Click here for further details. !6
  • 7. Agile Metrics Below are some metrics which may or may not be required for reportage: ❖ Sprint Burndown – Tracks completion of work through Sprint against the forecast given by the team ❖ EPIC and Release Burndown ❖ Tracks completion of work over a larger set of PBIs ❖ Gives a view of progress towards the next release ❖ Tracks progress towards Epics spread out between multiple Sprints ❖ Velocity - Refers to the average amount of work completed within a Sprint, measured in terms of story points or hours. You can make a correct forecast through this metric. ❖ Cumulative Flow Diagram (CFD) – A key metric to identify WIP limit of a team and allow correct batch sizes to be estimated ❖ Additional metrics (Optional) ❖ Pre-release defect count – How many defects were caught before PBIs were released? ❖ Post-release defect count – How many defects were caught after PBIs were released? ❖ Defects per Sprint – How many defects were recorded per Sprint? ❖ Planned-to-Done ratio – How many PBIs were planned across Sprints and of them, what was the ratio at which they were released? !7
  • 9. EPIC Burndown Chart This chart is used to determine when all EPICs identified for release will actually be closed based on current velocity !9 ❖ X axis - Sprint numbers ❖ Y axis - EPIC story points ❖ Dotted line - Trend line (Shows the general trajectory of the EPIC velocity) ❖ Solid line - Consumption of actual story points The point at which the trend line touches 0 is when the Project can be marked for RELEASE.
  • 10. Sprint Burndown Chart Used for any project which started on Agile and needs to track how story points or hours are consumed !10 ❖ X axis - Sprint days ❖ Y axis - Story points remaining to be implemented in the Sprint ❖ Trend line - General guideline where the remaining story points become 0 ❖ Solid line - Current situation of the Sprint w.r.t story consumption Solid Line Trend Line
  • 11. Burndown vs. Burnup ❖ The Burndown chart is a very handy tool for all Scrum Teams. Here is why: ❖ Provides a view of the progress to the team ❖ Shows when the team might be able to close all Sprint Backlog ❖ Provides the Velocity (Story Points/Sprint) which can be used for forecasting (using ‘Yesterday’s Weather’ mechanism) ❖ However, it does not answer these two pertinent questions: ❖ Was work added or was no work done? For instance, the example provided on Slide 10 between 2nd and 4th July does not give you an answer. ❖ How many story points are yet to be Validated? How many have not even been started? In the Sprint Burndown example on Slide 10, story points are clearly left to be completed on 12th July. The first question is answered by using a BURNUP chart. The second one though, is far more difficult and requires a CFD. !11
  • 12. CFD ❖ Shows the way tasks are allocated to different process stages ❖ Created out of different colored bands representing different process groups. ❖ Visually represents the following: ❖ WIP - The amount of work the team handles at any given point of time (In the above example, it is the “In Progress” band on any given day.) ❖ Addition of task and its rate - Was task added and if so, by how much? (In the above example, its the increase in “Open” on 24th May and 07th July.) ❖ Task deletion - Was task deleted and if so, by how much? ❖ Sudden rise or fall in activities - Shows problematic areas or possible bottlenecks !12
  • 13. Which Chart Should You Use? ❖ Depends on the project and audience ❖ Use a Burndown chart if: ❖ The project does not cause mid-project addition or removal of Backlog items. ❖ The project is for an audience, who are viewing the project progress on a regular basis. ❖ Use a Burnup chart or CFD if the project has multiple addition/ deletion of items mid-project. A CFD provides a lot more information w.r.t story point per process stage. This ,in turn, provides more transparency about team activities to all stakeholders. !13
  • 14. Additional Metrics ❖ Number of defects found per Sprint which shows the effectiveness of the Scrum team (See the example on the right.) ❖ A Planned-To-Done ratio bar graph for long-term projects !14 0 5 10 15 20 25 30 35 40 Sprint 1 Sprint 2 Sprint 3 Sprint 4 Sprint 5 Sprint 6 Sprint 7 Sprint 8 Sprint 9 Total Total
  • 15. Impediment Backlog ❖ Created through the Impediments faced by the team during Sprint ❖ Its resolution might arrive during the Sprint, where it can be absorbed. ❖ Alternatively, the resolution can be made available for future Sprints, where it should be converted into a Backlog item. ❖ An impediment backlog is an essential part of any practical scrum progress report and needs to be made transparent to all. !15
  • 16. Risk Assessment ❖ Risk assessment in an Agile world is best handled through ROAM methodology as given in Scaled Agile. ❖ This can also be used in simple Agile projects. ❖ This information is useful for stakeholders to see potential bottlenecks and react to them within the given timeframe. !16 Risk Item Id Details Resolved Owned Accepted Mitigated Action Action Holder S*_001 Full Product build for given product ID set needs to be available * Complete Production CI build setup to be completed by wk 2 Infra Scrum
  • 17. Your Progress Report for Agile Project In a nutshell, here is a conclusion to the essentials of the progress report contents for your initial Agile projects: ❖ It should hold a simple view of the success and failure of the team. ❖ It should provide a snapshot of all the scrum artifacts (as given in slide 6). ❖ It should provide an EPIC Release Burndown chart as part of the above point. ❖ It should provide one of the charts mentioned in slides 10-12. ❖ It should provide the Impediment Backlog. ❖ It could provide additional optional metrics as defined on slide 14 ❖ It should provide details of Risk Assessment. !17
  • 18. The End Profile – www.saugatadas.net Blog – www.saugatadas.net/blog LinkedIn – www.linkedin.com/in/withsaugata Email – saugatad@gmail.com