When we have a close look at the process steps of a typical agile software delivery team, we will realize what is going on there.

In the first one, “in Analysis”, we plan to create value. Once we have a plan how to add value for a user to our product we but this story into “Ready for Dev”. And here we are doing literally nothing, or, in other words: wasting time. In the best case, the story is still good to play – in the best case! Often stories are a bit outdated already before they are picked up and if they were lying around a bit too long they may even be completely degraded. In the next column “in dev” we are actually adding the value to the product and in the next “Ready for… “ process step we are – you guessed it – wasting time too. Until someone can check for the planned value and finally deliver the value. If we find a bug while testing, the deliverable software is in the state of analysis all over again – the bug is prioritized against other features and maybe fixed and maybe not.

As QAs we have little influence over the “Ready for Dev” column, but the “Ready for QA” is ours. Removing this column can have some positive impact on the velocity and quality if you pair it with another tool: work in progress (WIP) limits.

The idea is the following: if there is no “Ready for QA” column there is no place for a developer to just drop a ticket/story before picking the next piece of work. Unless the story was put directly into “in QA” (without anyone actually working on it). If the team then agrees on WIP-Limits, one could argue that a single QA person can work on one or max two stories at the same time. Thus, if there are already two stories “in QA” another one cannot be added. Thus, the story cannot move, thus the devs cannot start a new one (the “in dev” column should also have a WIP). The best way is to help the QA do the job and thus everyone gets more involved into testing – a big win for quality.

This will decrease the time to market for new features drastically. As a plus, bug-fixes can be delivered faster, too. Even in the standard process.

We applied these measure on different projects in different context. In one case, we were able to decrease the cycle time (= time from “Analysis” to “Done”) for stories from 13 days to 4 days – without anyone having to work “harder”. The restrictive WIP limits have a very good effect: if you can’t have so many stories in “in dev” you do not have to perform any context switches. You focus on getting one thing done before the next. Surprise: that actually helps to get things done! And being more focused on one specific task leads to fewer mistakes, thus fewer defects.

In another example where we applied the same technique, we were able to increase our velocity by a bit more than 30% (!) without any impact on the quality of the software.

These are some techniques to truly bake chocolate into the muffin: reduce waste in order to increase your focus on the really important things. Spend your available time on the urgent matters and “suddenly” you end up with a higher quality product.