Iteration Forecasting | Jesse Fewell

Iteration Forecasting

By November 25, 2005Blog, Uncategorized

So I was handed the project plan and the edict “Make the date or die!” (ok, not quite, but something like that). With such an agressive schedule, we needed to know that at any given step, we were headed in the right direction. At this juncture, the Agile methodologist in the audience would shoot his hand in the air, “ooo ooo me me, I know the answer” waving the agile manifesto in his hands. However, scrum recommends 1-month cycles, and extreme programming recommends 2-week cycles. Both of which would not provide enough feedback in the 1 month implementation time allotted (we had already eaten through the 1 month design phase doing mostly rampup). So, we decided on four 1-week iterations, mostly because it seemed like a nice round number, even though I couldn’t find much precident for it in the literature I saw (has anyone else seen 1-week iterations?).

Then we threw out the project schedule, and went back to the sponsor and asked “It’s been a while since the schedule was put together. Based on the WBS, exactly what high-level features do you need by the deadline?”. He gave us that list, each item having a relative priority. That in itself sounds like a typical 1-month release cycle you find in scrum. However, when we overlayed the feature-list on top of the four 1-week iterations, we ended up with what amounts to an iteration meta-plan: a forecast of what features would go into the upcoming iterations. Then, we honed down the details of the first iteration, and started executing.

It worked out really well for us for several reasons:

  1. Typically, agile projects focus exlusively on the release at hand, taking it on faith that the project sponsor or customer will push the right features at the right time. But when you’re dealing with stakeholders used to more regimented management approaches, that’s a big leap of faith. With all the deadline-sensitive features assigned to an iteration, everyone was confident we COULD meet the schedule.
  2. All the developers were fairly new to agile software development, and were uncomforatable putting off some of the internal quality issues that professional pride and crafstmanship demand be resolved. So for example, by knowing that integration between modules A and B was scheduled for week 3, they could sleep at night with the digital duck tape and bailing wire used to complete A and B individually.
  3. Because the team and the sponsor had a basic iteration template to go by, we saved time on our weekly release planning.

So by doing a simply hybrid of PMI’s “progressive elaboration”, and agile iteration planning, we made the deadline, everyone got paid, and I rode off into the sunset with the girl (in the minivan with the 3 kids, that is).

Leave a Reply