We keep our series of articles on how to estimate software development project right and make estimations your friends, not foes. In the previous post, we already covered main reasons why estimates can let you down and ways to avoid it. Today we will focus on practice and will tell you how estimates work on different stages of the project.
Before we start, we would like to explain to you one important thing – estimates in software development (and probably in the majority of other fields) is not some kind of constant. They can (and will) alter with the development of the project. Managing your own expectations regarding them is one of the main ways to get maximum from the information you are provided.
And now, let’s have a look, how estimates work on different stages of the project.
Stage 1. Initial Concept
Project Status: The client has only general ideas of what product he wants to develop. Details are not yet settled are due to change. No business analysis has been conducted yet.
Ambiguity level: Very High
Estimation Approach: Comparison to previous projects
This kind of estimates is given at the very beginning of the project. Basically, they are based on some vague idea of what the project will be about. Please pay attention that your and developer’s vague understanding can differ a lot. To estimate the project at this stage, developer usually provides the final estimates of a similar project that was recently completed.
Since no reliable details are provided, the estimates given at this stage are also quite unreliable. You can use them for general understanding of how hard it is to bring your idea to live, but besides that, they are almost useless.
Stage 2. Vision & Scope Drawn
Project Status: Some initial business analysis work has been done. Vision & Scope of the project have already been discussed and documented. This way everybody has much better idea of what is going to be included in the project. Documentation provides the list of main features to be developed as well as general understanding of what are the aims and limitation of the project.
Ambiguity level: High
Estimation Approach: Comparison to previous projects, Comparison to previous features, Assumption comparison
At this stage we already have some details to rely on, which can’t but make the estimates more accurate. Nevertheless, since only features list is available, the estimates will only give you a generic understanding of how much time will be required to develop the project.
Usually estimates given at this stage take one of 2 approaches:
- Developer provides estimate of a similar project completed recently. If there’s no project with enough similarity, each feature is estimated separately. This way estimation can be made based on a few previous projects that contain features from the list.
- In case there are still features that haven’t been done before, assumption comparison takes place. This approach is very common for Agile methodology. To use it, take 1 small feature you are experienced with as 1 point and compare all other features in relation to it. If you assume it is 2 times harder to develop feature 2 than feature 1, assign 2 points to it. After that transfer points to days (hours) and calculate final estimates. It is recommended to use this approach, when the amount of unfamiliar features is no bigger than 20%.
One of the most common mistakes made by clients is treating the estimates provided at this stage as final deadlines. We pay your attention that estimates provided at stage 2 are for reference only, so we highly recommend not to tie your marketing plan to them to avoid regrets in future.
Stage 3. Requirements Gathered and Analyzed
Project Status: This stage of the project requires not only the list of features, but detailed description of both functional and non-functional requirements. All the requirements are not only documented, but also checked that they match each other and no logic conflicts are included. It is a great advantage if UI Design and Wireframes are already completed, since they add even more details to the picture.
Ambiguity level: Low
Estimation Approach: Comparison to previous features, Decomposition
At this stage you already have a pretty clear image of what product is being developed. And estimates provided become much more accurate as well.
But don’t rush to put the estimated date as a deadline in your calendar. Always keep in mind, that there is a risk that some features or details were missed during Business Analysis stage. Besides, having the product developed, you might change your mind about some of the points. This way, though the estimate provided at this stage is pretty accurate, some risk buffer should be added as well.
To estimate the project at this stage developer usually splits each ticket in the smallest pieces possible. The better the split is, the more detailed the estimate is. Let’s see how it works on the example of a User Story, where User wants to see Book Review on a Bookshop Site.
- Here’s how initially the Use Case will look like.
- Let’s estimate the parts we split it in.
If you have subtasks, that will take more than 8 hours, it is highly recommended to split them into smaller ones in order to make management and development more transparent.
- Now it is time to think about additional work not included in development estimates. The most common ones here are testing and design. Add them to estimates as well.
- After you have the scheme with all activities, think about cases that might have missed out. A good advice here is to brainstorm how a User could possibly break the system and think of as many unhappy paths as possible. Add those that require some efforts from development side to the scheme.
After you sum all the subtasks up, you will probably have an estimate that is closer to optimistic one than to a realistic one. So let’s treat it as optimistic one, unless any special cases (e.g. you are very experienced with project like this) apply.
Now it’s time to provide 3 main estimates: optimistic, probable and pessimistic.
Optimistic, Probable and Pessimistic Estimates
Since estimates are such a complicated and changing thing, the best practice in Project Management is to provide 3 estimates: optimistic, probable and pessimistic. We have already told you how to get the optimistic one.
To get the other 2, multipliers are used. They depend not only on what type of estimate you want to receive, but also on at what stage the project is.
Have a look at the graph to learn how to do it right.
Using the graph, we will receive the following results for our example:
- Optimistic – 14h
- Probable (14h / 0,67) – 20h
- Pessimistic (20h x 1,5) – 30h
“Well, having 3 estimates is great, but I’d still would like to know, when everything will be ready”, – you might say. To get a bigger view on the picture, use the probability spreading function from Toma DeMarco.
It will let you see with what probability the project will be finished within the specified time period. We recommend you to rely you at least on 85% probability.
As you see, though estimates are a tricky thing, there is still a way to tame them and even make them your best friends. All you need to do is not to put too much pressure on them and remember that they can and will be flexible during the whole project development.
And what are your hacks to making estimates work? Share with us in the comments!
