Estimating in IT has been a difficult activity for a long time and actually it still is. Sometimes or even very often development of features is estimated based on a few sentences of requirements. There are no doubts that demanding an accurate estimate in such case is ridiculous. Actually, estimates are never accurate. But if everybody agrees that guesstimates are good enough and only very high level numbers are needed for each feature being estimated, why not to provide them? This article describes a way of marking features with low/medium/high cost markers when normal estimating cannot be done.

What and why?

Estimating is a process of using knowledge and experience to predict cost and/or duration of some activity. In IT, the activity could be a feature implementation. Estimating development of any feature requires some knowledge of the functionality. It is ridiculous to ask for a cost prediction if it is unknown what needs to be delivered.

How much do I need to know about the subject of the implementation to estimate? It depends, sometimes 500 words description is enough, sometimes 2000 words does not allow estimating with a reasonable level of comfort.
There are cases when requirements description contains only 20 words. Everything else is not decided, not discussed, not thought through. No matter how much ridiculously it seems, it happens and it is not so hopeless. Imagine, that you have a list of 50 not-yet-existing features for your system. Each feature has 20 words as a description attached. You are asked to estimate each one of them. Fortunately, the requestors are smart and understand the difficulties of the request so they ask only for marking each feature as LOW, MEDIUM or HIGH cost. It is needed for further “DO/DON’T implement” decision for each item.

Scrum estimates and LOW/MEDIUM/HIGH ranges

Scrum is an Agile methodology that has its own way of estimating development. The whole concept is based on focusing on relativity instead of predicting time. It is not a place for describing how to estimate in Scrum but this knowledge is important to understand the rest of the article. More on estimating in Scrum can be found on http://www.allaboutagile.com/how-to-implement-scrum-in-10-easy-steps-step-2-how-to-estimate-your-product-backlog/.

To summarize, at the beginning there is a list of 50 features:

• Feature 1
• Feature 2
• ...
• Feature 50

Step 1 Estimate using Story Points from Scrum

Gather the whole team and go through the list and estimate each feature with Story Points using Scrum. Yes, it is not as easy as it seems. You usually think about effort when you have more detailed requirements but you and your team have some experience in your environment. You know how much not yet articulated requirements will probably be added. If your Product Owner/Business Analyst has a big imagination and a tendency to fantasize, you can bet that “Implement sending emails.” will turn into sending attachments, antivirus scanning and archiving even if nobody has mentioned them yet. If you can tell from your experience that adding fireworks to a simple feature is not a common practice, don’t assume this time it will be an exception.

I can assure you, estimating 50 vaguely described feature will not be a piece of cake but it can be done. The key is to keep in mind that ultimately the estimates will be converted into three markers and to make sure everybody understand that the accuracy will be worse than any other estimate you have ever provided.

As a result you should have something like this:

• Feature 1 - 8 SP
• Feature 2 - 2 SP
• ...
• Feature 50 - 5 SP

Each feature has a Story Point estimate assigned.

Step 2 Group the estimates into three categories – low, medium, high

The second step is finding the border estimates between low and medium group and medium and high. It is easy if there are 10 estimates but 100 numbers may become difficult. It is good if each group has similar number of features but it does not need to be precise – just putting all of them into one category is not what we would like to have.

Usually, I use an Excel spreadsheet as shown in the screenshot below.

Then going from the top of the chart (highest estimates) to the bottom (lowest estimates) I decide where each category starts and ends.

The above example has the following groups definition:

• High – 20-100 SP
• Medium – 8-13 SP
• Low – 1-5 SP

It is extremely important to replace the estimates with the categories. We do not want anybody to stick with those numbers. They are even less accurate than real estimates. There were almost no requirements written down, remember?

Step 3 Provide your boss with the categorized features

Here is my example would finally look like.

If the requestors need hours or mandays instead of Story Points, you can recalculate the category ranges by multiplying by the current Story Point / manday ratio.

Why not to estimate using low/medium/high?

You can see, I proposed estimating in Story Points then changing them to the low, medium and high groups. The reason is simple – the team is not used to think in terms of such groups. If you always estimate in Story Points, there is no point in changing that no matter what units your boss wants on the report. Proper recalculation can be done afterwards.

Check also - https://www.toptal.com/project-managers/scrum-master/agile-project-estimation-techniques