When will it be done?

When will it be done? A simple question, but one that can seem impossible to answer. In 2019, my team and I attended a two-day workshop on Advanced Agile Metrics by agile expert and veteran Dan Vacanti to understand how to answer this question. After the workshop, we put our brand new knowledge to use. Just a few changes in our work process have helped us improve our velocity and predictability, even through challenges like the pandemic and consequent organizational changes.

My favorite takeaway? Limit work in progress.

Do less, ship more

One of the key takeaways from Dan's workshop is to limit the work in progress. As engineers, we love to code. It’s common practice to pull in the next ticket to In Progress as soon as the current ticket enters Code Review. Unfortunately, if abused, this practice can lead to situations where we have a lot of tickets stuck in one of the progress states.

Biting off more than we can chew ends up with time spent shifting focus on getting stuck tickets moved to the next goalpost. Sometimes, this leads to work not being done as quickly as we had hoped. And so, we are unable to comfortably predict how fast we can move work to completion. Whenever this happens, it skews our metrics, making it difficult to answer how long it actually takes to get the job done.

Work In Progress(WIP): Tickets that have been started but not yet completed.

Instead of dealing with unexpected pileups, Dan suggested limiting work in progress by placing explicit limits on our sprint board columns by considering the number of developers on the team. In our case, we elected to set our WIP limit to 10.

There is a scientific principle behind this, called Little's law. When applied to software development, it translates to this: The more tickets you take on, the longer it may take to finish. When WIP is in the acceptable threshold, it indicates to us that we can pull in the next piece of work.

Limiting WIP did initially feel like we were slowing down. Working only a single item at a time, in reality, meant we were being better shepherds of our work and were getting more tickets across to the finish line.

Over time, we noticed a decrease in cycle time and an increase in throughput. By working on only one item at a time, we are able to reduce the risk of downstream delays and work out how long an item took to complete. Another positive side effect of limiting WIP is that it enforces our team to better focus on our product and customer commitments by controlling the work itself. We have to decide each time what we should focus on in this sprint that has the most impact.

Item age: Time between starting on a ticket and now

Besides limiting WIP, we also track our progress using Aging Charts instead of only looking at our sprint board. The aging chart gives us insights into how long it is taking for tickets to progress towards completion. Our team conducts stand-up twice a week—Monday and Thursday mornings—and instead of a round-robin approach where each team member gives an update, we simply look at our aging chart. If tickets are blocked or just so complex that they take more time to complete, we can quickly focus on moving them towards completion.

Putting this key takeaway into our workflow has helped us improve our predictability, speed and reduced pile-ups as we complete each sprint. The time it takes for us to complete work is now much more accurate. It can even be used to confidently predict how long it could take to complete certain initiatives. Limiting WIP and paying attention to item age allows us to focus more on the part we love the most—building and shipping software.

Dan Vacanti’s workshop: https://actionableagile.com/

If limiting work in progress appeals to you, come join us!