Sprint Reports - Context is KEY

Its all grey

Throughout my career, I have found that sprint reporting is a real grey area when working scrum. The reason for this is because of phycological safety of the team and the misconception and negative actions that can be taken by management upon their review.

If you just look at the numbers then you will have no clue as to how the team really performed and the challenges that the teams face. This will very quickly prevent any improvements from being made, especially at an organisational level. Aside from this, we look to increase velocity and this means challenging ourselves.

Often, a good delivery manager or scrum master will be able to understand how the squad feels about the data that we share and we should consult our teams on this to some degree. That said, scrum is about transparency and continuous improvement. This being the case, sprint reports, or any type of reports for that matter, should be explained to the audience so that people are aware of what the data means, why we deliver it and the actions that we should take after review.

What I have observed

I have worked in organisations with real agile appetite where the senior leadership really wanted to understand what I was presenting and wanted to make improvements off the back of the data. In this scenario, there is often little that we cannot share.

On the flipside, I have worked in organisations who don't really care about the context, just want to count the tickets done, the story points achieved and compare each squad against each other. This is a huge misunderstanding of agile working.

Each team may measure story points differently, there is no standard to what a point actually means and is defined as the teams mature. Tickets may be written at higher or lower levels of detail depending on the product managers, product owners, business analysts or the squad in general. Ticket counting and point counting between teams is a game for cowboys. Leave the agile space if this is you.

If you don't want context then why even do scrum? you will never improve because you don't know the challenges.

Why is context so important

Let me give you a hypothetical scenario.....several teams fail to hit sprint goals as they have dependencies on infrastructure; several teams report this as reasons that they have failed to hit goals. This may not be easily spotted specifically if it happens over time. It may be that the senior management look at this and decide to embed infrastructure engineers with the squads, they may decide to implement new tools to help automate process or even requisition new roles. If you only look at the numbers, you only see failure and much needed action may not be taken.

This could also be something more subtle, we may find that front end tasks are never completed on time. This could be due to the incorrect disparity in the team, too many back end devs and not enough front end or it may be that the back end devs arent working on the blocking tasks first in the sprint. So the action needed may be internal to the squad or an organisation change. In more detail, you may want to move a back end dev to another team or move a front end dev into the team. or you may want to ensure that we take into account internal dependencies and order of development when refining and planning the sprint.

If I work in an organisation that disciplines and compares teams based on data, especially with no context then I would be very hesitant to share a comprehensive sprint report. This is because I also have a duty to protect the team. There are times when people underperform, but this shouldn't be dealt with in front of an audience.

Agile Dave, is there anything that you would exclude from a sprint report regardless?

Yes, what went well, what didn't go well from the retro. This should be something that the team shares internally and regardless of how safe the environment is, reporting failures in such a way will halt improvement in its tracks. People will stop being honest about themselves in fear that this will be under the spotlight. When talking about what went well, peoples work being excluded will have the same affect.

I do include actions from retros as I feel that this will help other squads and the organisation to improve and bring awareness to what is needed for this improvement to take place.

AgileDaves comprehensive sprint report

So, here we are, the moment we have all been waiting for;

As I have stated, I will explain this report here but what I would add, is that I have never shared this full report in an organisation. This is because I feel that I am duplicating my efforts but, if you want to pick and choose which slides you take or even take none, rip it apart if you wish, go for it. It's free and is available to you out of the kindness of my heart.

I wanted to give a special mention here to Chris Moore and Sharman Bhatt who created the format for page 1 (I have made a few amendments to the original)

Sprint results - The numbers

Table -

The numbers here are ultimately a reflection on how the sprint ended and I measure this both in tickets and in points. Some may say ticket numbers don't matter but I disagree, I feel that this could indicate that we need to break tickets down more or maybe they are written at too low a level.

• Not started will be value of tickets that were not yet started when the sprint ended, same with in progress and done.

• Planned is ultimately what the team planned to do at the start of the sprint

• Planned vs Done % is the percentage of work the team did vs what was planned

• Scope change documents what was added or removed from the sprint

Sprint Goal -

This is what it says on the tin, the most important metric of the sprint. Some will say that this should be simply met or not met but I disagree. The ability to offer value even when we cannot meet the full sprint goal is the sign of a mature scrum team. To give an example, the goal may be to create a form and a number of automated functions based on the input. We may not complete the automated functions but complete the form to capture the data. Capturing the data may still hold value to the end user and we may have had to make adjustments throughout the sprint to ensure that we delivered this value to the end user. There is room on the report to add this context.

Summary -

This is where we summarise the numbers and what they mean and is a good platform to start conversations on wider improvement if needed.

Burndown and retro actions

Burndown chart and commentary -

I have lumped this into one page as often don't report cycle time. This is because I am involved with the teams that I work with and the context is often similar to burndown if there has been an impact.

Reporting this will help to visualise the challenges of the team and also the success. We can often comment of how a bottleneck was caused or when we strategically made changes. We can also educate if we work in an organisation where scope is often added to the sprint and how this impacted the team.

Retro actions -

As stated above, I report this as this should be something that helps to improve other squads and the organisation in general

Cycle Time

This can be used much the same as burndown to talk about why some issues took longer than expected. Cycle time often lets us examine this at a lower level of detail than a burndown but personally, I am very involved with my teams so I have already understood this and commented in the burndown commentary.

Sprint Velocity

This should be used to show how the team is improving and measure an average velocity which helps with estimations and becoming predictable. Again, you should always add context to this. You can talk a little about how recent sprint compares to previous sprints but remember, you will have already reported previous sprints.

If you just know the numbers then you are missing important contributing factors like team members on leave, other commitments outside of the sprint that were not identified or dependencies. This is an important metric and can really help the team drive forward and challenge themselves.

What we did/What is next

What we did -

In an ideal world, the sprint is made up only of tickets that contribute to meeting the sprint goal, but this is not always the case. The team may have delivered other value that that doesn't form part of the sprint goal. This allows the audience to really see all of the great work that the team is doing.

What is next -

Here we can simply add the sprint goal for the next sprint.

Final thoughts

Please don't share sprint reports with nothing else but data, they are basically useless and spit in the face of agile working. The whole point of data is analysis and analysis can only be done with the right context. The idea behind a sprint report is not to only review the performance of the team but to see how the team can improve. Take the audience on this journey, the audience may well be the people with the power to help implement the changes needed to improve. Context is KEY!!!

To download my sprint report, follow this link here