Applying Queuing Theory to Sprints

Queuing theory is one of those subjects that you learn in college but you never completely understand, like calculus or algebra. The problem with it is the little practical use you make of it.

I realized some time ago, that Quality Engineers (QEs) in my projects were not doing much during the first half of the Sprints and this had a recurrent pattern; they created test cases, preparing testing environments, updated existing ones, did some research, wrote training documents, etc. That sounds kind of ok, but the problem was that by the end of the iteration, they were all of a sudden overwhelmed by the amount of user stories they had to test. Consequently, they had to work killing hours (including weekends) to get the work done.

I remember that time ago, banks had a similar problem, tellers where not doing much during most of the day, but at peak hours they could hardly breathe because they would have a bunch of impatient clients formed on a line in from of them. Banks played smart and did something to improve their service systems and evenly distribute arrivals. Queuing theory-wise, if you can't increment servers, go in the other direction and look for a stable arrival rate.

It's pretty obvious that we have a lesson to learn from banks and other service industries. So what can we do in order to help balancing Quality Engineer's work? Some ideas below:

1. Plan for micro-deliveries, small pieces of functionality should be passed from development to quality assurance on a daily basis, if possible.
2. Don't pass code that is not on a build for testing, builds are great for version control and integration testing.
3. Automate as you implement, run Build Verification Test on a daily basis.
4. Write test cases as you progress with testing; don't wait to have tons of test cases written before starting to test.
5. Sync developers and QEs’ efforts to know what to implement and test.
6. Don't plan for large user stories, break them into smaller chunks of functionality–use the INVEST principle.
7. The acceptance criteria is not fixed, it evolves as the functionality is implemented and tested–it certainly exists from the beginning but should be refined as we move into the sprint.
8. Look for people that are sitting idle because they're waiting for something to test, waiting is waste and has to be eliminated.

The ultimate goal should be to have a stable flow of code from development to quality assurance and vice versa. A stable flow is what will allow you to make better use of your QEs reducing queues’ length and decreasing throughput time for user stories.