PROBE or PROxy Based Estimation Using Active Time
Proxy based estimation (PROBE) is a technique for estimating that is derived from the Personal Software Process (PSP) from the SEI. The idea is attractive because it provides guidance for how a developer, or a team for that matter, can categorize their historical estimate data so that it can be meaningfully used for future estimates.
The technique goes like this –
You analyze your work and categorize it into the units or types that you typically deliver your project features or other work in. I'll give you a simple example for my own activity. I do quite a few presentations in PowerPoint. I categorize my typical slides into simple text, table or data driven examples, high degrees of graphics or charts, and automation. Each area, for me at least, implies more complexity and thus more time to create.
These become my work proxies which drive my historical data collection.
Once you define your proxy index table, you start capturing estimate and actual data for the various categories of work that you typically perform. Obviously the data becomes more valuable as –
- You collect more data samples for each proxy for your work
- Refine the proxies in size and complexity to align with your work artifacts
- Your experience in interpreting the historical data—towards estimate formulation increases
Here is a tabular example representing my earlier proxy:
| Type of slide / Complexity | Simple | Moderate | Complex |
|---|---|---|---|
| Simple Text | < 5 lines | < 10 lines | > 10 lines |
| Moderate Research | 1 source | 2-5 sources | > 5 sources |
| Objects, Tables & Graphs | < 2 | < 5 | < 10 |
| Automation | < 20% | < 50% | Near 100% |
If someone asked me to estimate an approximate 100 slide training class, I would first decompose the class into types of slides I would generally expect it to contain. For example, 20 simple slides, 60 of moderate complexity, and 20 with a lot of complexity and automation might be a reasonable decomposition for a standard 1 day workshop.
Next I would evaluate estimates and actuals from my historical data to gather some samples of my own execution. Using this data, I could extrapolate and make some reasonably accurate estimates on how long it will take me to pull together the class. As I completed the workshop, I would add the estimate + actual pairs into my database for future reference.
As you gather more historical data, you start to narrow the estimate uncertainty for any specific type of task. I hope you see how this relatively simple example can be extended into your individual and team software estimation.
But how does this map to 6th Sense Analytics?
You have finely grained Active Time data available at an individual and team level that accurately represents all work activity. First, Active Time becomes your actual measure for any estimate—easily captured via queries or status reports. You'll also want to start estimating in Active Time as well.
There are several advantages to this. First, Active Time naturally masks out all of the non-work activity such as meetings, sick time, etc. So you won't have to factor them into the estimates. Second, since 6th Sense Analytics is collecting your Active Time, either at an individual or group / project level, you can easily track progress to the initial estimate and gather actual effort upon completion.
If you do any research on PROBE you'll notice a lot more to it than I mentioned here. For example, there are some linear regression calculations that assist in narrowing the estimate uncertainty from the samples within your historical estimate and actual data sets -- this significantly increases the accuracy of your overall estimates.
Previous Post:
SVG Presentations in July 2006
Next Post:
Pareto in Software - A Powerful Tool
