← Back
A project manager is faced with the limitations of binary project management tools.

From Burndown to Burnout: Part 1 — Resolution

The sad state of process analysis tools

May 18, 2023
Chris Stoll
Co-Founder | CTO

The tools of the trade for product management simply aren’t fit for the purpose of understanding and instrumenting a complex business process. We know this in our bones—we laugh at viral videos that point out the ridiculousness of our daily lives, but until now, we haven’t been able to put our finger on why these broken tools exacerbate the waste that builds up in broken processes.

Leon Figures Out Why the JIRA Reports Are Always F'd Up on TicTok

Andrew and I have been thinking about these problems for years, and we’ve come to the conclusion that there are three main reasons that analysis and reporting coming out of current project and product management tools leads to so much waste.

  1. Resolution – current analysis frameworks are too binary
  2. Breadth – current views, particularly of “product management” are too narrow
  3. Chronography – current platforms have insufficient understanding of “time” and how it relates to process flow

In future posts, I’ll expand on breadth and chronography. But for now, I want to dig into the resolution of modern software tools.

At a fundamental level, the way we track projects tends to be very binary. Almost every tracking tool has some version of a “burndown” chart, showing how much progress is being made against a defined unit of work. The tasks in that chart fit into one of three status types. (I know, I know—having three states means it’s not “binary,” but bear with me.):

  1. Todo
  2. Doing
  3. Done
Burndown charts be like this meme

And the assumption is the work is flowing to completion as each task moves from “Todo” to “Doing” and then to “Done.” How work is progressing becomes a really simple measurement: what percentage of that work has moved to a “Done” state. Here’s a representative burndown chart from a recent Bloomfilter sprint. It shows the amount of work left to complete.

Bloom Sprint 17 screenshot

The problem when trying to understand how the work is progressing is you have zero sense of what’s happening inside these states.

At the most extreme level, a sprint where all the tasks are in testing but not deployed will show the same burndown chart as a sprint where the tasks have yet to be started.

Well, burndown is just one chart, right? We can just look at something a little more sophisticated to get a more nuanced view. Maybe we look at cumulative flow?

Cumulative Flow Diagram - In Production

Hmmm… That’s…unhelpful. All the signal of the process flow is lost amidst the noise of the “done vs. doing” dichotomy. Perhaps the chart will become meaningful if we remove the “In Production” (which for some reason is cumulative for all time) in hopes of getting to a finer resolution of this particular sprint.

Bloomfilter Cumulative Flow Diagram - In Production excluded

Unfortunately, now that we’ve lost our “In Production” tasks, the process flow chart loses all continuity and meaning. Are tasks leaving “review” because they’re being deployed? Are they being deleted? Who’s to say? There’s simply no sense of what’s happening inside the process.

I could go on like this forever, cycling through charts in hopes of getting some meaningful perspective on how the sprint progressed, but I suspect you’re getting an idea  just how productive that exercise is going to be.

I won’t even bore you by trying to stitch this together across multiple tools instead of one product management system (I’ll save that for the breadth post) or trying to do more time-series analysis of the process flow (that’s coming in chronography.)

If we want to understand how the process of product development is working and where to find inefficiency and waste, the most fundamental analysis tooling we need is the ability to look at the process (in a meaningful way) at various resolution levels. We need to be able to zoom out to get a fuller view of the process. We need to be able to zoom in to see the individual tasks, all without breaking frame. We need to be able to do this across arbitrary time frames and filter that data in various ways depending on the needs of the business and analysis.

A big part of the reason product leaders have to spend so much time exporting data into Excel is that current tooling simply doesn’t support varying granularity in the resolution of process data that it displays. It’s too binary. It’s too focused on “to do,” “doing,” and “done” despite the fact that those starts obscure as much as they illuminate.

A modern approach needs to focus on peering inside the three binary states to let a product manager understand what’s happening inside the process. Software leaders need to easily understand (at various levels of resolution) where work sits, where it’s flowing, and where it’s getting blocked. A modern burn chart needs to overlay work that’s complete with work in process and in various other states to easily understand the status at any given point in time.

Bloomfilter Burn Tracking screenshot

Similarly, a modern process flow analysis platform must be able to depict the process flow at a resolution that’s meaningful. In the chart below, the user can easily understand the state of work, where it’s sitting, and where there might be process issues to remediate.

Bloomfilter Burn Flow screenshot

Modern software development tooling, especially process analysis, is broken. Most tools provide unhelpful or even potentially misleading information to the users who are trying to build and ship products. We’ll get into some of the more complex topics in future posts, but the first and most obvious place platforms need to evolve is with respect to the resolution of the data present. Simply put, process flow data needs to be presented in a frame that is accurate and contextually helpful to the user—a concept that seems simple enough but is almost entirely absent from current state of the art.

The Human Cost of Inefficient Software Development
4 minute read
The Human Cost of Inefficient Software Development
When it comes to software development, inefficiency isn't just a budget issue—it can have a significant human impact. In this post, Andrew Wolfe, our co-founder and co-CEO, shares a deeply personal experience where a promising medical project was derailed by these issues. This story (and others like it) fuels our mission to change how software gets built—for the better.
Andrew Wolfe
Andrew Wolfe
Co-Founder | Co-CEO
Introducing new product metrics to better understand your SDLC health
5 minute read
Introducing new product metrics to better understand your SDLC health
When's the last time you took the pulse of your SDLC? We're pulling back the curtain on a fresh set of metrics in this post. Take a look at how we're shaking things up and making software process analytics more transparent and predictable.
Brian Kurr
Brian Kurr
Lead Software Engineer
Why AI Needs Process Intelligence
3 minute read
Why AI Needs Process Intelligence
Explore the impact of AI on software development and why embracing process intelligence and transparency is essential for navigating this brave new world.
Andrew Wolfe
Andrew Wolfe
Co-Founder | Co-CEO