2 ways the State flow chart helps agile teams

To build Insight we talked to quite a few project managers and CTOs during the past year. We learned a great deal about their every-day reality and the challenges they are facing every day.

One of the things that kept coming back was that it's hard for them to find bottlenecks even when they have a strong intuition on where the problems might me. So we started looking for a solution...

The idea for the state flow chart took shape while talking with, Michael, a project manager who had to deal with a completely remote team and needed to have a bigger picture of how the work was progressing during an arbitrary period of time.

It became very clear that the best way we could spot bottlenecks would be to visually trace how the stories move from one state to the other during a period of time. We started prototyping on a paper and brainstorming on what it should look like if it was to be displayed as a chart.

Today it's very similar to the first draft except it's much simpler and more flexible.

Picture of  the current state flow

Quality issues

The stacked bars represent the story states and the grey lines represent traffic between 2 states on a daily basis.

Most of that traffic should flow downwards and to the right as stories move from started to accepted. It's a sign that everything is working fine.

If this chart consistently shows paths moving upwards, from delivered to in-progress for example, it's a sign that the team might have quality issues or maybe the definition of done is not clear enough for the whole team.

The paths are proportional to the number of points that flow through in order to give users a visual cue of where they should focus their attention.

Clicking the paths and the states can help find out which stories are affected and adding a cycle time chart is a good way to have a different view on problematic situations you might see in the state flow chart.

The visual aspect of the state flow chart is optimized for finding bottlenecks, so let's have a look at some use-cases.


If QA is not done regularly, it is basically stalling the process because those stories are not being accepted or rejected and re-worked on. This is a problem because the company invested money in those stories and they are stalled waiting for QA, not delivering any value when they could. If those stories get rejected, the developers have long since moved on to something else and they are no longer in the context of the rejected stories.

In the State flow chart, users can detect this behaviour by watching all the traffic covering into the delivered state until the last day. This is clearly a bottleneck that needs to be addressed if the team wants a lean process.

Every team is different

I only mentioned some common examples, but every team has it's specifics. The state flow chart can combine multiple projects, labels and teammates in order to respond to those specific use-cases.

The state flow turned out to be one of the most popular charts we built so far and even though in the surface it didn't change much since it's creation, we did remove some visual noise and improve it's overall aspect.

One last thing, We now have a discussions section. If you have other examples or ideas or if you disagree with something I said, share your thoughts below.