Tuesday, March 18, 2008

March 18, 2008 - Estimating Lessons Learned - Agile Methods

One of the most pathetic looking sights on the highway is a man walking, head down, with a gas can. He represents the ultimate in poor estimating practices. It is bad enough that he ran out of fuel, but he was probably already late or he would have stopped to get gas. Having the embarrassment of trekking back to the car only adds to his dilemmas.

One of the misperceptions of Agile development is that the team continues to code until they “run out of gas” by hitting the target date.

Lesson 5 – Agile development requires estimation.

Although non-traditional methods differ in their techniques, they still rely on estimates to plan for and meet projected dead lines. We’ll look at three different types: Predictive Modeling, Time Boxing and Planning Poker.

In order to be effective, each of these estimating types requires a prioritized list of functionality and features that define the scope of the project. SCRUM estimates items on a Product Backlog. In the Rational Unified Process (RUP) Use Cases are identified and estimated at a high level (ex. 2 days for A and 5 days for B). XP uses Stories. The difference lies in the way the estimates are determined.

Predictive Modeling involves breaking the product into pieces and assigning relative work units to each one. For example, you may assign feature X 5 units and feature Y 10 units because Y is 2 times bigger or more complex than X. Initially you predict the duration for the first set of features and extrapolate the full project effort based on those numbers. Upon completion of the first set you have a better idea of how long it will take to complete the next, allowing you can refine your prediction. As each piece is completed you can more accurately estimate the remainder of the project.

Time Boxing is based on the concept of set periods of duration, anywhere from 1 to 6 weeks, for each release. Based on their size, complexity and dependencies, Use Cases (or features) are scheduled for specific releases throughout the project. At the end of each release the next set of Use Cases is re-evaluated to verify that they are the right ones and that they can still be completed in the timeframe. If a trend begins to appear showing that the team is consistently falling behind, the overall project schedule will require re-evaluated.

Planning Poker is a variation on the Wideband Delphi technique. In the 1970s Barry Boehm and John A. Farquhar expanded the US Armed Forces’ Delphi method to use multiple experts giving anonymous estimates for pieces of a project. Those estimates would be reviewed and the pieces with big discrepancies would be discussed in meeting and re-estimated.

As with every other aspect of development, Agile decided to speed up the process. In a Planning Poker session, team members are given cards with numbers on them, representing work effort (i.e. 3, 5, 10, 20 hours). Individual stories are reviewed and discussed by the team. Each member then selects a number from their deck that corresponds with their estimate. Only after everyone has picked a number do they show their estimates. If the numbers are close together, the value stands. When there is a large difference, additional discussion is held and another secret estimate is held.

Each of these estimating types has their strengths and weaknesses. Sometimes it is best to use a different technique for different parts of the project. The key will be how you explain and communicate the numbers to the project stakeholders. We’ll cover that next time.

1 comment:

Josh Nankivel said...

An excellent summary Thomas. I'd like to add that the other methods you mentioned in prior posts of this series also apply to Agile methodologies. I personally have found analogous and parametric methods powerful when using SCRUM, because you have new information after each sprint to apply to the next sprint.

In particular, if you keep a sprint log properly and track your time on the individual tasks, they can be used for analogous and parametric estimates going forward.

I have been frustrated too by those who see Agile as a way to get out of planning. Some even insist that the very next day after a release, the new sprint should be in execution mode. If you've got month-long sprints, it is my opinion that the team should spend at least 1 full day planning the next sprint fully before any coding commences.

Josh Nankivel