Learning from your Burn Down chart

The chart to the left represents the Burn Down chart for the Secret Server 4.1 release which shipped on March 14th 2008.  We have always shipped Secret Server on the published date (or in the early hours of morning the next day!) but this release pushed things a little too close for our liking.  What was the problem?  Did we take on too much?  Did we trade off scope like we are supposed to?

Looking at the Burn Down we can see that our velocity was really low in the early stages of the release.  This was mostly due to some support issues that drained our development resources and also some staff shuffling on projects which lead to inefficiencies.  We were able to make up for this with a phenomenal increase in velocity in the final iterations.  Unfortunately this was achieved by using more team resources to accomplish the tasks.  While the increased velocity is good, it also means there was a greater rate of change in the codebase at a point where quality assurance was trying to stabilize the product.  Test Driven Development certainly helps by allowing us to lean on our regression suite of tests but it is still not ideal.

So what went wrong?  We will be having a recap meeting later this week to determine how to improve our planning for future releases. We need to get back on track to our usual release schedule where we are ready for the actual release days before the release date (not bad for a small team with frequent releases!).  I think part of the problem was not planning properly for reducing scope.  We left one of the larger features of the release until the end (the Role Based Security feature) - then we didn't recognize that this feature could be thinned out to reduce scope but rather implemented most of the originally specified functionality. 

Typically our team cannot easily change resources (cost) since most team members are committed to projects and cannot easily shift responsibilities.  We also can't change the date since customers are expecting a release on a particular date because sales and support have been giving this date out for a few weeks.  This only leaves scope as the final equalizer to make timely releases possible.  In future, we will need to be more careful to ensure that scope can always still be reduced if necessary.

What does your Burn Down Chart tell you?

We are hiring!  Do you want to write beautiful code in a Test Driven, Refactored, Agile .NET software company in the heart of Washington DC and work on cool products? 
Take the code test and send your resume along with why you want to join Thycotic to tddjobs@thycotic.com.