Estimation, one of the biggest dividers between engineering and product. Accurate estimates are one thing that product and the client require the most from developers (especially at the early stages of a project) and the one thing that the developers find hard to create accurately (again especially in the early stages of a project).
The trouble is that there is a certain level of uncertainty, expectation and scope that is not always easy to define at the beginning of a project. Especially in Agile.
Hopefully this post will outline some of the difficulties and reasons of expectations from both the development AND product perspectives, so we can better understand how each other operates, and why we get into troubles when using estimates.
Fair warning! Some contents of this article may be highly opinionated.
Estimates – What are they good for? Absolutely nothing?
While this header is me having a bit of fun, there is a certain truth to it. When a developer is asked to give an estimate (even a ‘high level estimate’), product is essentially asking ‘when do you expect this will be done by’. The developer is answering the question, ‘when is it “probably” going to be done by?’
The issue here? The word ‘probably’. By definition to estimate is:
“To roughly calculate or judge the value, number, quantity, or extent of”
(Definition of estimate from Webster’s Dictionary)
The main problem with general estimates (especially when we use days) is that we are giving a single solid number, when actually an estimate should be a probability range.
Instead of ‘We estimate it takes 5 days’ it is more accurate to say ‘We are 80% certain that this will be done within 5 days’.
These estimates will be used to plan work (Why wouldn’t they be? That’s what they’re for). However we need to understand that they are just estimates. There is a high degree of guesswork involved. Educated guesswork, but guesswork nonetheless.
How can estimates be useful
Product and/or the client need to know when to expect something. I mean how can they run a business on inaccurate data? Well there it is. The great big mahooosive elephant in the room! How can developers give product enough information to accurately plan. How can our estimates be useful to anybody?
Well here are a few thoughts on this.
1. T-shirt size epics – This gives us a general feel for how much work is involved in an epic. It is extremely high level as we might not have 100% of the requirements or details yet. Take this with a pinch of salt.
2. Prioritise your epics – Make sure that the development team know what you want and in what order. If things do go wrong with timescales (Lets face it. It’s not entirely unlikely), we know that the things of least importance are the ones that are going to be dropped. It’s also worth noting here that prioritising your epics means ordering them in a list. No two epics can have the same priority (No more 7 P1s and 13 P2s I’m afraid).
3. Estimate stories – Re-evaluate your time lines when you have more detailed estimates in your stories. If it looks like the stories are bigger than the original estimate of the epic, make sure we can adjust the schedule accordingly. Also do this regularly! make sure your estimates are up to date based on new information!
4. Don’t try to have everything for a deadline – This means, if you have a hard deadline, you need to see what is achievable by the deadline instead of saying what needs to be achieved by the deadline. No amount of pressure is going to change the laws of physics.
5. Beware of ‘trying’
If a developer says they will TRY to get something done, do not take this as a guarantee that it will get done. This basically means we’re going to do our jobs and make our best efforts to deliver what we can in the given time scale. It doesn’t mean we’re working any harder to deliver. We’re already doing that before we say we’ll try.
On another note, developers should also not commit to ‘try’ to do things. This implies that the development team is slightly under-promising or slightly over delivering. If it is a case of try, then the work is definitely being underestimated. If things don’t fit, something has to give and we have to have a discussion about what will and won’t be included. We need to compromise on a way around the issue. Can something be delivered in an easier way and replaced after launch? E.g. Instead of a dynamic date picker, can we have a simple text box with validation, then create future stories to put in the fancy calendar after the initial delivery? (I know this is not a big issue these days with pre-built components, it is just an example)/
Thoughts continued…
6. Estimate are not values – A developer giving an estimate should give a range that they expect something will be completed in. One good practice of this is the use of an ‘optimistic’ value (typically < 1% change of happening), ‘nominal’ value (typically best guess at when it will be done), and a ‘pessimistic’ value (hopefully, pretty much a guarantee that the work will be done by this point). These values can be used to highlight the risk of a ticket.
7. Estimates have a certain level of assumption in them – An estimate is a case of ‘this is how long we believe it will take when x,y and z are true. These assumptions should be documented in tickets as part of requirements. If any of these assumptions are false, then the estimate is null and void
8. No one person should estimate – Estimates are a group activity. A single person should not be responsible for providing estimates. The more people involved, the better the estimate. When using optimistic, pessimistic and nominal values in your estimates, the entire team should estimate all values.
Now for a bit of a visual
As I’ve alluded to before, estimates are not a value. They are a range. A range based on probability. This range can be displayed in graph for as per the example below:
This graph above is a ‘probability density function’ showing when a ticket is probably going to be complete. The X axis can be any method of estimation (e.g. days, story points, etc). Here we can see where it will likely be complete and where it COULD be complete. Anything after the nominal outcome is a risk. Taking this into account both development and product should be able to see where risks to the ticket and overall schedule lie.
The above image is where we have a decent understanding of the ticket. However, if there is uncertainty or ambiguity in the ticket, the risk will trail on further.
The above graph you can see that the left side of the graph is steeper and the right hand side of the graph (showing the risk) has a longer downward trend. This is because we know more about the ticket for shorter durations (i.e. we know enough that we know we can’t do it in that time scale), but there is uncertainty in the ticket, which means the higher ‘pessimistic’ estimate is much further away from the nominal outcome. This highlights uncertainty from the developers perspective, which also shows a greater risk to the schedule. In short, there is a direct link to uncertainty and risk.
We can use these estimates (optimistic, nominal and pessimistic) to determine values such as the ‘likely’ value for completion and the ‘standard deviation’. The standard deviation can then be used to further determine the risk.
For further reading check out Paweł Świderskil’s review of Uncle Bob’s estimation talk
Effective Estimation Review of Uncle Bob’s presentation
The images are sourced from a similar Microsoft Press article found here:
https://www.microsoftpressstore.com/articles/article.aspx?p=2191414&seqNum=3
Conclusion
Estimation is a pain. They are hard. Estimation is misunderstood! As both developers and product we need to all understand what each of us means by the word ‘estimate’. We need to be sympathetic to each other. Developers should understand that product (and/or the client) NEED this info, as accurately as possible, in order to schedule when we are going to likely deliver products. Product need to understand that developers are doing their best at estimating the work, but it cannot guarantee completion. They should also ensure that there is ‘wiggle’ room to drop stuff (and have this as a standard expectation of a common result) when things go awry.
As the old quote goes ‘Plans are only as good as the first contact with the enemy’. In this vein as soon as the project starts there will be more known, and of more complexity discovered on epics. Developers should be encouraged to (and not penalised) to at the first opportunity where epic estimates / schedules need to be adjusted.
The more we know, the more accurate we can be. However, we can’t plan everything up front (like we used to do in the “good old” waterfall days), because requirements and designs have a habit of changing. So we need to be able to adapt to change and be agile.
“Information is power, and the value of information decays over time”
(Quote by Sam Edwards – Senior Engineer – Truepill)
The schedule needs a certain amount of flexibility, which should be an expectation of the product and customer.
Hopefully from the above we can all understand one another better, as well as get better at estimations.
Wouldn’t that be great 😀
Thank you to David Johnson for allowing us to share this article on our website.
If you would like to be featured on our guest blog, get in contact with the team here.
