In other post we reviewed an estimation technique. If you do not handled that technique, here I present how to implement it using some tools. That technique is mixing other well known techniques. It’s based on PERT and Scrum Poker, plus some basic formulas to allow you to create more precise estimations, according an average measurement made by your developers — the people who really is doing the job and knows more about the development. Also you can use a trusted team to create the estimation, you just need a spreadsheet, scrum poker cards, and a well identified WBS or user stories.
The first step is to identify what will be the work to execute. You can use a WBS or user stories. In our example we will use a very simple functionality: “The user sends contact information (Contact Form)”. Since the user story is big, since it requires to be divided in various tasks, we will organise the work as WBS with one level — where the parent level is the main task “The user sends contact information (Contact Form)”.
- Create the HTML Layout and Controls
- Create the Validation JavaScript
- Apply design
- Create the Server Side input handling (from the HTML form)
- Create the Server Side validation
- Create the Server Side form processing
- Create the proper Unit Tests
This requires that the developer must know HTML and must know JavaScript. Why I have ordered “Apply design” at third place?. The reason is simple, this creates a lightweight work load. If you have standard the form control naming, CSS class naming, HTML organisation and related stuff, you do not need to create CSS styles twice, adapt HTML templates to work with JavaScript and you will not require to adapt your JavaScript code to new CSS. For example, the typical double work load made for .NET applications is made because most development companies are starting with the HTML design first, where every control html ID is changed on runtime on the server side, then you have the developer migrating those HTML ID driven CSS selectors to CSS Class driven selectors, and similar stuff. Well, that do not have a real importance, I think that .NET developers are loving to double work and most self assessed Web Developers do not have idea about HTML and CSS.
OK, we have our WBS for the Contact Form task. On Scum Poker, each developer throws an estimate on each WBS task or user story, in this case we have identified each task related to the Contact Form functionality or user story, and placed them into a simple WBS — remember that this is only an example. Once all developers on the team had thrown the estimate, each developer defends his position about the user story or task, then all developers agree with the most consistent estimate. If you have an average development team, you will that most developers will agree with certain estimates. Well, instead of using only one estimate, we will use PERT based estimates, asking each developer for the three PERT estimates: pessimist, regular and optimist. We can organise the time for each task on the spreadsheet as follows.
| No. | Task | Avg. Pessimist | Avg. Regular | Avg. Optimist | PERT | Depends | Note |
|---|---|---|---|---|---|---|---|
| 1 | HTML Layout and Controls | 03.00 | 01.50 | 01.00 | 01.93 | — | Controls do not have a table layout |
| 2 | Validation JavaScript | 02.00 | 01.00 | 00.50 | 01.29 | 1 | We can’t use a JS framework |
| 3 | Apply design | 03.50 | 02.50 | 01.00 | 02.75 | 1 & 2 | Must be compatible with IE7 |
| 4 | Server Side Input Handling | 03.00 | 02.50 | 01.00 | 02.60 | 1 | We can’t use Form Class and Interfaces |
| 5 | Server Side Validation | 02.00 | 01.50 | 01.00 | 01.64 | 4 | We can’t use Exceptions |
| 6 | Server Side Form Processing | 03.00 | 02.50 | 00.50 | 02.61 | 5 | We can’t use third party components (i.e. mail processing) |
| 7 | Create Tests | 01.50 | 01.00 | 00.50 | 01.13 | 6 | We can’t use an UT framework |
| TOTAL | 18.00 | 11.00 | 04.50 | 13.95 | — |
PERT was calculated using a confidence level of 80%. And average times in hours were taken from 5 developers — in this example. So, finally “The user sends contact information (Contact Form)” user story will take 13.95 hours to be completed. This estimation is made from the experience of a group of developers, and not using arbitrary times. The discussion generated on the scrum poker session is a good time to take some feedback about the customer requirements. So, creating a good estimation for a project do not takes too much time with this technique. I’m very sure that using the experience as basis of estimations will guide you to more precise estimations and well done software projects.
Entries 
[...] A Mixed Technique for Estimations [...]