/
Insight
Logo
Insight

Deliver more by starting less

The work in progress of your project is the number of stories that are being worked on at any given time. This number can vary based on how big the team is, how well the stories are defined or understood and sometimes how much external interference affects the development team.

So let's see how we can deliver more work by controlling the work in progress (WIP).

An example image of the work in progress (WIP)

What's the problem exactly?

To better illustrate the problem, I really like the traffic analogy Dave Sharrock brings in this post.

Basically, it explains how an increased density of cars slows down the traffic flow and it leads to an even bigger increase in car density which in turn causes even slower flow, and so on...

In a project it would mean that the more stories we start, the more work we have to deal with simultaneously and the slower those stories will be moving towards completion.

In other words, if you work on multiple things at the same time, much of your time is spent on switching between tasks. Constantly starting new tasks makes it really hard to keep a clear mind as you are never fully focused on finishing a task.

How do we fix this?

Stop starting and start finishing. — David Anderson

Limit the WIP

Set a limit of how many stories your team may work on at the same time, then track and enforce that number. A good way to do this is to make it visible for the whole team and also have a visual indicator alerting everyone when the threshold is reached.

Limiting the number of stories will ensure everyone is focused on moving things forward instead of starting to work on something else every time impediment comes up.

Nothing should interrupt what is being worked on.

A lot of teams get interrupted with last minute priorities that keep changing. This is often a problem when stakeholders can come in and talk directly to developers. If this is the case for your team, it's one of the first things you need to fix before you work on anything else.

Stakehloders should prioritize the stories in the backlog that are not yet started, but should be unable to influence what developers are working on.

Stalled stories are a priority

If a story is stalled, don't switch on an other story, stop everything else and focus on moving the stalled story out of that state.

Avoid distracting the team.

The team doesn't necessarily need to be distracted by the whole backlog, developers mostly need to see what they should work on now and what is about to come. It's a good idea to have a shorter to-do list than the whole backlog even if it is well prioritized.

Write good user stories.

The more granular and well defined your stories are, the lower chances you have of blocking a developer on them. Since it's everyone's responsibility to respect the WIP limit, everyone should make sure that the work that is about to get started is well defined.

Good domain knowledge will always make a huge difference.

If the team has a good domain knowledge, they are much more likely to solve bottlenecks faster. Developers that have a good domain knowledge will make better decisions without external help and research which means that they will solve bottleneck more efficiently.

It's all about focus

In the end, the single most important thing to increase your productivity is to have your team as focused as possible on a minimum set of well defined stories.

The best indicator to track if you are starting less and getting more done will be the WIP. Set a threshold and make sure everyone can see it.