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.
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.
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?
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.
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)/
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.
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
The images are sourced from a similar Microsoft Press article found here:
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”
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.
“After many years in a HR role, in Stephen and his team at Candour, I have finally found the recruitment agency that is totally attuned to what Phoenix as a company requires. Candour is my one-stop shop for technical candidates!”Trevor Hutchinson, Phoenix Software
“Stephen did a great job of filling a Lead Software Engineer role that was proving very difficult. He submitted a range of quality CV’s quickly and followed our process throughout.”Becky O'Farrell, Covea Insurance
“I’ve worked with Stephen for around a year and we have developed a good working relationship. The Candour team are always available so there is never a gap in communication. This is so important when time is tight and you need to find the best talent as soon as possible.”Abigail Aldred, CNG
“When first speaking to Stephen, he had an honest interest in us as a company, not just what we needed experience and tech-wise, but the culture and the type of person we wanted to join. He gave frank and honest feedback to us and he filled the role in less than 2 weeks!!”Sophie Elms, Arbor Education
“What makes them stand out is that they truly listen to what our requirements for the perfect candidate are. They deliver on what they promise, and I very much feel they are working with Phoenix Software to ensure the right person for the role is recruited.”Clare Metcalfe, Phoenix Software
“I receive numerous pitches from recruitment companies. All promise, very few actually deliver. Stephen and the guys at Candour definitely fall into the latter category. They have become a vital part of our recruitment process and act as an invaluable extension of our business.”Taryn Mitchell-Clegg, IDHL Group
“They have never failed to deliver and always goes the extra mile for their clients and candidates (having been a candidate for Stephen myself too). As a small business, Candour truly understands the importance of finding the right people and help you cut through the noise.”Claire Penswick, CNG
“Stephen of Candour have managed to fill 3 QA Test Analyst roles for my team in Manchester. I was impressed by the quality of candidates they supplied.”Isha Soni, Push Doctor
“Stephen and the team found a selection of good candidates in very short timescales, this gave my team good options and ultimately providing the person we were looking for.”David Topley, TSYS
“Stephen has helped us to find very skilled resources for our open vacancies. I presented him with some challenges and he delivered extremely good candidates that we were struggling to find.”Mauricio Farache, Piksel
“Stephen is laser-focused in understanding a requirement and then proactively identifying ‘best in class’ candidates. It’s clear that he puts in the extra effort to find only the best – whatever it takes – and this makes for a very effective partnership in any recruitment.”Joel Albyn, Cap HPI
“Stephen consistently finds quality candidates that others seemingly cannot. This has been no more apparent than in the last few months where I have given him two very difficult technical requirements that he has filled in less than a week.”Jonathan Hill, GameSparks
“If you are looking to partner with a recruiter who will actually add value to your business and do what they commit to doing, I strongly recommend Stephen.”Gabriel Page, Amazon
“Stephen is simply one of the best recruiters in the business. He understands my needs as an employer and how to get results with the minimum of fuss. He gets you what you need, when you need it on time and on budget.”Samantha Allen, SSP
“Over nearly 10 years I have been lucky enough to take on many Engineers that have been supplied through Stephen and his company. Many have been the most talented individuals that I have had the privilege to work with, and all have enhanced our business positively.”Bruce Cass, Piksel
Candour Solutions market knowledge & advice in relation to market trends & recruitment processes, has helped us reshape our own process.Rose Laksevics, Tes