This blog is part of a series exploring Agile methodologies. Read the last post in the series here. This post will explore Agile estimation and the different estimation techniques.
Estimation is more the “art” than the “science” of program management so polish the crystal ball and let’s get started.
Agile estimation is fundamentally different from conventional waterfall estimation. Waterfall tends to be “bottom up” while Agile is “top down”. The waterfall approach for estimating projects is to spend several weeks or months at the beginning of a project defining the detailed requirements. Tasks are defined and resources are assigned to tasks. The detail must be defined before cost and schedule can be estimated.
The drawbacks to this approach are that things change rapidly in today’s environments and the proposed solution can quickly become obsolete. The top down (Agile) approach uses Rolling Wave Estimation incorporating new information as it is discovered and adjusting to the rapid changes as the project progresses. This allows for the rapidly changing requirements in today’s software projects.
ESTIMATION:
There are three levels of estimation in Agile:
- Proposal/Project Level – performed during the initial phases of a project
- Release Level – plans the release of features bundled to provide frequent and rapid delivery
- Sprint Level – planning of the tasks associated with the completion of individual stories in a sprint
ESTIMATION TECHNIQUES:
There are several different types of estimation techniques at each level.
On the project/ proposal level, one could use statistical models based on the past behavior of the teams. This is part science and part intuition and must be adjusted as the team evolves.
On the release level, there are several popular estimation techniques such as:
- Affinity Mapping
- T-Shirt Sizes
- Dot Voting
- The Bucket System
- Planning Poker
The important thing to note is that all of these estimation systems involve collaboration and comparison.
To make a real life analogy on comparison, say you go for lunch at a restaurant. The waiter asks you what size soup you want, cup or bowl? You know a bowl tends to be twice as big as a cup but you don’t know how many ounces are in the cup or bowl. This is an example of relative estimation, are you really hungry? (Bowl) or just a little? (Cup)
Another fascinating aspect of Agile estimation is using the Fibonacci sequence of numbers to estimate relative sizes – entire white papers have been written on how this natural sequence of numbers follows so many natural patters in our universe and I will discuss this sequence in more detail in future blogs.
One of the most critical aspects of Agile estimation is the fact that one constantly adjusts as things change. For this reason, it is not really possible to plan too far into the future as, if you do, you will inevitably, have to plan again.
Till next time.
