The document outlines key considerations for progress reporting in agile project management, contrasting it with traditional waterfall models. It emphasizes the importance of periodic status updates in complex projects and provides a list of essential artifacts and metrics for effective reporting. Additionally, it suggests the use of different charts, such as burndown and cumulative flow diagrams, for tracking project progress and managing risks.

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