Work in Progress and Done

One finds that when SCRUM teams start with development, the team takes on a bunch of tasks and starts marking them as Work in Progress ( WIP ), so you find yourself seeing a sharp spike upwards on the WIP status which results in an interesting situation as the burndown occurs.

You might think that this is correct practice, getting many things fired off at once and then converging down to "done done". Well, based on my experience and articles out there, that's not a good thing. Its far better to get to done items quicker in the sprint by having teams focus on getting the tasks done vs the "spray gun" approach.  What can happen is that  you can mark that 80% of work is done but only 20% of your features get done, there is a great example of this when google was working on the the adwords project ( I also experienced similar behaviors with teams when I first implemented SCRUM at my previous companies).

The best technique is to put a couple of engineers to work on the particular feature and tasks in a more serial fashion so that the features get "done done" and move to the next item in the list. You drive quality and reduce the "work in progress" gaps

Here is a chart ( borrowed from Ken's talk at google, that represents the idea). Too  many tasks, marked in Yellow, represent tasks which are started but in complete, White represents the Burned tasks("done") and Red are the not started tasks. The goal is to make the burndown more lean and reduce the amount of parallel tasks which are started and increase the amount of burndown tasks which are "done". The bottom line is that the higher the white in the chart below the higher the quality and features complete and the better chance you have in finishing, versus, the higher the yellow in the chart the more risk of having a slower velocity in completion.

thoughts and comments are welcome.