The 3 Simple Reporting Mistakes Most Dev Teams are Making

Reporting is, in many ways, straightforward. In others, it’s less so.

For most teams, reporting is time-consuming, whether it’s sprint reporting, Kanban reporting or any other kind of operational report on software engineering processes. But it’s one of the most important things we do to keep various groups of people aligned.

So we need to get it right.

All too often, that’s not the case. Reports don’t really solve the problems they’re meant to, they lack focus and they take too long to create.

I boil this down to three simple reporting mistakes engineering teams make.

All three waste time, focus, and money.

And we’re going to talk about each of them – followed by some good practices – below.

1. Too much information

Good reports give a clear, unobstructed view of what’s happening (or not happening).

They’re going to show the people reading them the stuff they care about, and they’ll do so concisely and clearly.

They do it without overwhelming our audience.

Some obvious bad things happen when we get this wrong (and some slightly less obvious).

• Long reports don’t get read. 
• Reading fatigue sets in and the stuff that matters gets missed
• There’s diluted impact because the stuff that matters is buried
• Long reports aren’t as accessible, both to busy stakeholders and neurodiverse folks
• We waste time and energy not only reading them, but creating them
• They have less referential utility – they’re unlikely to be used as quick references and lose more value, faster
• We lose sight of strategic objectives and goals the report is meant to address and support
• We make more poorly-informed decisions
• When we have information overload, we don’t retain the stuff that matters

‍

Often, the reason reports are overloaded is simply because the people writing them are unclear who they’re for and what purpose they serve. Or, it could be that one report is attempting to serve multiple purposes, and in doing so, serves none well.

I often see teams overload reports because agile teams, scrum teams and those that lead them are unclear about what their goals are, or which projects are really driving the company forward.

Centre reporting on clarity, purpose, and audience relevance.

2. Different reports, different people

Different stakeholders require different information, and different levels of granularity.

When we get this wrong, reports can end up being anything from overwhelming to useless.

Your engineering manager needs a totally different update, covering different themes and agile metrics, from your C-level.

For example…

Team leads need the specifics from the trenches. Daily tasks, day-to-day progress, and granular challenges arising. They’ll track key metrics like velocity and completion rates, and want a flag of any potential risks so they can take corrective action.

C-level execs need a totally different level of granularity. They want to understand if strategic projects are on track and how sprint goals align with their broader objectives. They’ll probably want this accompanied by a flag of significant milestones, challenges or scope changes without any detail.

Some reports are going to need story points, and burndown charts; others will need velocity charts, and sprint progress updates – the point is that reports need to be written with specific groups of readers in mind.

Of course, there are numerous other use cases for reports. But creating them is not a one-size-fits-all activity.

3. Reporting is a gargantuan affair

If one person per team spends two hours each week writing a report, and one hour chasing people for updates, that’s three hours a week, or 156 hours per year. If you’ve got ten teams, that’s 1560 hours per year, or 195 days per year.

If the person writing them is earning $75,000, an hour of their time costs roughly $36. 

So that reporting is costing your business roughly $56,000 for your 10 teams.

Now imagine that for each team, 10 people read the report, and it takes them 10 minutes each. That's an additional 100 minutes or 1 hour and 40 minutes every week, or roughly 110 days every year, costing $31,200 – though your leaders probably earn more!

Reporting isn’t revenue-generating either, so perhaps even more importantly, it also has an opportunity cost, taking time away from core development activities.

Continuous interruptions to chase – or give – updates also break focus and momentum.

So we’d better make that time count.

Small reporting changes you can make (for a big impact)

1. Know your audience.

We all know that different groups of stakeholders have different needs and priorities. When we report, we need to consciously write for our audience – bearing in mind their level of project understanding, and technical understanding. In all cases, clarity is key.

2. Make it objective-oriented.

When we report, we’re not just presenting data, we tell a story that leads back to objectives and goals. Objectives should guide what we include. Start with an end in mind. What do we want readers to take away?  Thinking this way keeps reports focussed on what matters.

3. Create regularity. 

If you have to chase people for updates, set specific, regular times and deadlines for those updates to create a predictable rhythm and minimise disruption to work.

4. Optimise for skimming. 

Not everyone will read every word. Make it easy for readers to extract what matters. This should encourage writers to keep concise and save time, too.

5. Streamline the process. 

Do what you have to in order to cut the amount of time it takes to find data, updates or any other crucial information. Surface that information with automation tools or, increasingly, carefully selected AI tools.

Report regularly on Agile progress?

Until recently, reporting necessarily involved a substantial degree of human input.

With my team, I’ve built an advanced GenAI tool that makes agile reporting both accurate and effortless, with my team at Stepsize.

It’s called Stepsize AI.

Stepsize AI observes everything that happens in your issue tracker (such as Jira or Linear) and uses AI to form connections between tasks, activities, and more. 

That means it can…

• Give spooky accurate summaries of your progress
• Share the metrics that matter, including velocity, completion and allocation on a project-by-project basis
• Surface the true progress of each project (as well as any problems)

It uses these live observations to deliver super accurate and automatic weekly product development reports.

Of course, you can add more detail to your AI-generated report if needed – but every report is accurate, concise, and even contains links to sources so you can find more information with a single click.

Stepsize AI works brilliantly whichever agile methodology you use, including Scrum, Kanban, Lean, FaST, FDD and more.

I’d love your feedback on how our reports help you get aligned and save time.

You can check out Stepsize AI for free here.