Sprint Reports — Good or Bad
Transparency and Visibility
Visibility and transparency are two key tenants of agile.While we say working software is the true measure of progress, there is more to progress than working software when it comes to working with multiple teams having dependencies and integrations. In enterprise environments a team is seldom an island — you need to work with other teams to deliver end to end outcomes. Having worked with many different enterprises, I consider “visibility of progress”as basic hygiene. Whether you use a real time dashboard OR a physical board — it really doesn’t discount the need for providing visibility.
In a distributed world you have multiple stakeholders involved throughout the delivery cycle apart from your Product Owner, you need a way to demonstrate progress updates for the entire extended team of people.
When it makes sense to have a sprint report?
In my view, sprint reports are not evil.
1. When you don’t have real time dashboard or tool to visualise progress centrally at one place, for all practical purposes you should have a lean 2–3 pager view to keep your stakeholders informed.
2. In case you are already using planning /tracking tools like Trello, JIRA, TFS or VersionOne etc., you could create a dashboard with relevant details and share the link with relevant stakeholders. You don’t need a separate report in this case.
3. In case, you don’t have a tracking tool or the access / licensing etc. block your way, you can fall back to lean 2–3 pager sprint report. I am not an advocate of 20 page long status reports — that’s not how we demonstrate progress. Such lengthy reports are used as tools for contract conformance and manipulating the ground reality with colours and percentage. The Sprint reports that I am talking about are no more than 2–3 page long and should not take more than 20–30 minutes to prepare.
It’s a fact based data driven representation of ground reality — summarised and focused for decisions and actions!
But we don’t do such reports in agile?
Not having a view of progress and hiding behind “we are agile, we don’t do progress updates”, to me are two anti-agile behaviours.
If you stakeholders are highly engaged with your teams on day to day basis, face to face and have no outside stakeholders to provide progress visibility, you might just as be right with not having any sprint report. However, having such stakeholders and environment is a journey of trust building. It sounds too good to be true where your all your stakeholder would have access to your dashboard or available face to face when required and purely involved to make your team successful. In real world, most of the senior leaders have multiple initiatives and many teams to deliver business outcome — you would need a way to bring team level progress visibility to senior management. Sprint report can prove to be a good “adapter” to plug in your senior stakeholders to your team’s progress “socket”.
How does a Sprint report look like?
A sprint report should have a view of following:
1. How you are tracking to sprint goals?
2. Your current sprint burn-down
3. Current Build Version and Download/access information — In Dev, UAT, Prod etc.
4. Your Team Happiness Index i.e. how your team is feeling? Are team members engaged?
5. Customer Feedback or Satisfaction Index
6. Risks, Issues, Assumptions and Dependencies
7. Defect Summary / Trends
On closing note, I would like to reiterate that not having an integrated tool or realtime time dashboard should not be used as an excuse to not provide visibility of progress. User a simplified lean format to capture sprint outcomes and progress for your stakeholders.
Are you using Sprint Report in your agile initiatives or are you using real time tracking tools & dashboards? Please share your views!
