Estimates are very important for any kind of project, including those projects that require the use of agile, there is no question about that, but this brings to the foreground another set of important questions:
- how do we use estimates in an agile project?
- are there differences in the use of estimates with agile projects (when compared to the use of estimates in “traditional” projects)?
To be able to answer these questions, we need to explore some important characteristics of the nature of the projects that require the use of agile.
So, what’s the deal with the nature of certain types of projects that require the use of agile? Well, the kinds of projects that may need the use of agile have at least one of the following characteristics:
- The company is exploring and developing an entirely new business model, so, business rules for this new business model are being explored and understood along with the project.
- The company is developing a new type of product or service based on a new type of technology, so, there are no experts as this is a new field.
- The company is using new software tools and technologies, or is adapting and customizing open source tools to its own needs, so the dev team has no experts on these tools and technologies.
If the company in question is a startup, the project will have all these characteristics, but even if the company is not as startup and/or the project has only one of these characteristics, it clearly will benefit from the use of agile.
So, the main factor in each one of these characteristics is uncertainty in a very high order of magnitude, very much in line with the kind of uncertainty you would expect in a typical Research and Development project.
In fact, agile projects and R&D projects share enough elements in common pertaining to the impact of uncertainty, that some of the project management tools and techniques that apply to R&D projects may also apply to agile projects.
One such tool that is useful for agile, just as it is useful for R&D projects, is the PERT estimation formula. Even though the historic background of the development of the project management tools collectively known as PERT is really interesting, it makes more sense to focus our attention on the estimation formula itself.
In agile projects as well as in R&D projects we may have a group of experienced professionals exploring how to solve a problem while “navigating through uncharted waters”. Under such circumstances, when trying to work out estimates, they will offer a range of values for any given task, from optimistic to pessimistic, and with some intermediate values being the most frequently proposed.
Taking this into consideration, the PERT estimation formula is based on a skewed distribution, the Beta Distribution, that properly takes into consideration the nature of such processes. Duration estimates are always positive, and it makes sense to use a balanced approach capable of compensating for overly optimistic or overly pessimistic values used in the estimation process.
The PERT estimation formula is very useful to provide “good enough” task duration estimates provided by experts under conditions of high uncertainty.
For this case, the estimation value is based on the median for this skewed distribution.
The PERT estimation formula expression is the following:
Te = (To + 4Tmp + Tp)/6
Where Te is the estimation for the duration of a given task, To is the most optimistic value for the duration of the given task, Tmp is the most probable value for the duration of the given task, and Tp is the most pessimistic value for the duration of the given task.
This estimation formula offers a balanced approach based on a weighted average, giving more importance (4 times more importance) to the most probable value, while still taking into account both optimistic and pessimistic values.
In an agile project, how do we get the values to apply to this formula?
It would be in meetings like the Planning Game, or in a Sprint Planning Meeting where the team can obtain estimates from the team members for each task, and out of the range of estimate values for each task it would be easy to determine the 3 input values for each given task needed for this estimation formula.
For each given task, the most optimistic and most pessimistic values are easy to determine, but the most probable value is not that obvious to determine. The most probable value is the mode, and the team must create a histogram for each task with the value of all the estimates for each given task. The mode corresponds to the class of the histogram that has the tallest bar. Sometimes, histograms for estimates look kind of weird, like with more than one hump (that’s a multimodal histogram): we will discuss about that in a follow-up post.
It is very easy to determine the mode for any list of values with a tool like Excel or Open Office.
This sheds some light on what approach to use for task duration estimation out of the range of values that the team proposes for each task during any planning meeting, but it does not offer many clues regarding the differences (if any) on how to handle estimates in an agile project. We will discuss this in a follow-up post.
Kind regards, GEN