Today the Rentals.com team joined up with out RentClicks counterparts to estimate a joint project that was less the trivial in scope.  We started with a simple model of where we were and what needed to be changed, in what way, and then broke that down into digestable chunks.  We estimated each one as a team and I was surprised by how easy it was to have agreement with vague requirements.  We had a feel for what we needed to do and a hunch as to how long it would take.  Its fantastic to see the team operating as one with such efficiency.

After we logged points for each story, I counted up the points and came up with what represented, according to our time to point conversion factor, 10 developer weeks.  A quandry came over me as I realized we'd landed two months late on our current release and began to wonder how to factor that into our planning.  It is not reasonable, after all, to assume the same thing would not happen again.  A suggestion was made to bloat the estimates with a fudge factor.  This is the traditional way to account for unforeseen circumstance when plannig a project.  I think this would take 3 weeks so I'll add 30% to account for things that I haven't thought of.  I used to do this myself with amazing accuracy.  I'd tack on 30% to all my estimates and I would almost always be right on the money.  Something didn't feel right, however, with that approach.  First, this was essentially just lying strategically.  We think it will take two days so we'll say three?  Considering the whole purpose for using points in place of time is that you can adjust point translation according to circumstance...  ah hah!  The amount of work you can accomplish per iteration is called velocity.  Don't adjust the estimate, adjust the velocity!

During our last project, we lost one developer and I was split between two independent products.  I was also distracted with unrelated initiatives that sucked most of my time and energy and effectively lost me to the team.  This contributed to our missed Dec 20 target date.  Missing that date introduced the holidays which pretty much eats a week.  Then a separate, unplanned release was inserted right in the middle that caused a slide in both schedule and scope.  None of these things were accounted for in our project plan.  When something impacts the project, its important to reflect that in some visible way against one of the vectors of the project projection.  Its either going to complete on some other date or scope myust be adjusted to accomodate the changes.  The preferred approach is to adjust scope.  I did not and therefore had no idea when things would wrap up until the project started to show a steate of completion.

The appropriate thing to do would have been to subtract the scope of the developer who left and calculate the new velocity.  Then we should have reduced the scope of that iteration to meet the date planned for delivery or, if necessary, change the date. 

Looking back, this is what makes the most sense going forward.  Rather then fudge the estimates in some arbitrary way, I've tried to calculate the impact of the lost developer and the holidays and factor in the intermediate release.  From there I think a 30% factor is appropriate for adjusting or plan.  Rather then bloat the estimates, I will reduce velocity for iteration planning by 30%.  This will visibly show that we are experiencing some inefficiencies that have reduced our productivity.  If this is concering to decision makers, its a great topic for conversation.  Why have you reduced your velocity to 66 points per 2 week iteration?  ...well, our last release was off track and we're adjusting to reflect that something is slowing us down.  Our goal is to bring that back up to 80 points per week and we're activley seeking ways to accomplish that.  The reduced velocity will keep everyone aware of our present condition.  That's not a bad way to talk about it.  Its a good measure to keep an eye on and set a goal against.  In fact, the two new developers on the team will only provide a fraction of their optimal velocity until they are through the HR hurdles, familiar with the product and work flow and have their environment configured.  Now its really making sense.  We have a logical way say, "this is a two week task but it will take us a little longer."

Frankly, this was a good day