Estimation: the fine art of guessing
– The Agile Samurai
Not just ordinary guessing. Educated guessing. The better you know math, the bigger chance your estimations will be closer to predicting the actual efforts, costs, and workload. But is it just about the numbers? No, but more on that later.
Why do we need estimations?
How long will it take? How much will it cost? How many people will be needed to carry out the project?
These questions arise inevitably during the product lifecycle. Estimates help dispel doubts and manage uncertainty, improving the development process. Individual actions constituting projects often have an approximate duration (writing a particular piece of code, integrating pre-made modules, etc.). Joint efforts need to be calculated based on the available resources and information, answering the burning question the client has – when can my customers use the final product?
Estimations provide a tangible idea of the costs, time, and workload necessary to achieve desired goals. The more-or-less rough idea helps in deciding on project progress, and as such is an integral part of the software development process.
Why do estimations go wrong?
Approximate calculations aren’t an exact science, as they are based on uncertain information, and their outcome may be affected by various external factors (sick leaves, service provider downtimes, etc.). Nothing can guarantee 100% certainty, yet we still aim to find a middle ground, balancing customer business needs with the technical capabilities to satisfy them.
Do estimations always go wrong? That depends on the margin of error or the measures taken while estimating. But, to be perfectly honest, they very often do go wrong.
What does it mean wrong?
What are the symptoms of mishappened estimations?
- a task meant to last a sprint, or to finish within a set deadline was not delivered on time
- a task meant to last a sprint was delivered by a developer during a sprint, but without leaving a time margin necessary to carry out testing, bug fixing, or deployment to the test environment
- the task was delivered on time, but the number of man-hours exceeded customer expectations and estimates. The problem may arise from not taking into account the Project Managers’ work or tasks performed by the Tester or Analyst. This may lead to an unfavorable situation, affecting both the provider company and the client.
What does a wrong estimation cause?
Discrepancies between the estimation and the outcome can afflict both parties – the client will receive a higher invoice than agreed prior. Conversely, the service provider will profit less if the issued invoice amounts only the estimated amount of burnt time. Inaccurate estimations affect the decision-making process, detriment project management, and can, in the long run, disrupt the company overall operations and profitability.
How to estimate better? (and remain sane)
Estimate twice (at least)
Unrealistic estimations can be avoided – or at least, minimized – if performed twofold.
The rough one
The first attempt is a broad approach to a new project, moving from general to specific considerations. A precise collection of client requirements is necessary to understand the project scope and define further actions.
At this stage, the team can assess the idea’s feasibility, evaluate if the development might take weeks or rather months and whether domain experts on the client’s side can be engaged. Once an outline is agreed upon, a more specific estimation can be performed to be presented to the client.
The smooth one
While the rough estimation determines the initial scope and leads to the decision on project engagement, further evaluation concerns fractions of this field. The smooth one is rather a series of estimations performed underway, e.g. during sprint planning. The in-depth assessment is based on final requirements and acceptance criteria, instead of initial concepts and assumptions, and occurs during the project lifecycle in estimating particular functionalities and solutions.
To increase the chances of success, project managers also take into account non-technical aspects. Issues like workload of team members (in case developers work on several projects simultaneously), holiday season, or even the flu season affect operations, and can’t be overlooked.
Ask questions. Then, ask them again. And again
One of the reasons estimations go wrong is the misunderstanding of the project core, often caused by poorly collected requirements. The team acknowledges the idea and may picture something far different from what the client imagines. On the other hand, creators sometimes tend to believe what is perfectly understandable to them, will be just as clear to those hearing about the project for the first time.
Wrong estimations (both under- and overestimated) result from a misunderstanding of customer requirements, or an incorrect comprehension of those. Even though during the analytical discussion both parties may be convinced everything goes well, future events could show how the perceptions differed, resulting in an escalating misunderstanding. One of the causes is the so-called “curse of knowledge”, a belief of the client (or the analysts & programmers!) that what is obvious to them, is equally clear to others and as such, doesn’t require detailed explanation. The result? Each party interprets the generalities according to their own definitions, which could be completely different from what the other party intends. To avoid misunderstanding, at the stage of determining the final shape of the functionality, the parties need to assure they’re on the same page and use the same wording and definitions.
Aside from innovative, previously unknown solutions, the above issues can occur in seemingly simple topics. If the client wishes to e.g. launch an e-commerce platform, developers know what to expect, more or less, including using well-known tools or pre-built elements. What they do not know is the complexity or unusual features the client wished to include but didn’t express the agenda, thinking the idea is as clear to the developers as it is to them.
Ask questions, even if they may sound silly. What kind of e-commerce platform? What integrations will it have? What kind of functionalities? What does the end-user do, when adding items to the cart? What is the cart? Will the abandoned cart wait until the users’ next visit? Will it be available once the platform is accessed via a different browser?
Furthermore, paraphrasing is highly advised for a thorough understanding of clients’ ideas. Team members responsible for gathering requirements need to make sure they grasped the topics correctly, interpreting what the client said, repeating it in other words.
That’s just a sample, but it gives a general idea of how deep the team needs to look, to know what is ahead of them while collecting requirements. Inquire, dwell and question everything, until you have the idea broken down into the smallest pieces, enabling the team to understand the topic as thoroughly as the client does.
Ask the analyst
Direct involvement of an analyst reduces risks of misestimation, providing as much precision as possible. While the client is often a visionary delivering an idea, the analyst is the voice of reason, a realist reminding of the down-to-earth requirements and needs. Atop strong involvement in gathering client requirements, analysts provide diagrams, charts, and summaries, bringing together all the data regarding the project. This helps in real-time visualization and understanding, coming in handy especially for non-technical clients struggling with the tech side of the process.
Aside from the mentioned earlier paraphrasing, visual representations, the estimating process benefits largely from tools like Event Storming. The workshop-based method helps to model processes in the form of an event flow, with the participation of all people engaged in its creation and subsequent automation (clients’ employees, end-users, and the development team). Event Storming allows achieving a consistent language of requirement definition, exploring complex processes in detail, identifying potential gaps and problems which may lurk in overlooked areas, and indicating areas difficult to implement, raising clients’ awareness of the issue’s complexity. The method is unparalleled in increasing estimation accuracy, providing the proper understanding of what is estimated.
Prioritizing
Starting the product creation, it may be tough to refrain from diving headfirst into the development process, hoping for a pixel-perfect outcome right away. It’s the team’s job to educate and inform the client on best practices, e.g. starting with core features. The items that can bring value shortly should be created in earlier stages.
Once tested, the product’s first phases can go live and reach customers, while additional features will be delivered in the next iterations. The more the clients know, the better for them, and the process itself. While prioritizing may be challenging (who wouldn’t want to release in one shot a complete product, with all the bells and whistles?), some time needs to be devoted to determining product stages.
Another factor causing wrong estimations is taking into account only the functional requirements (“what” needs to be done), without considering the non-functional aspects (“how” it is going to work). The “how” part includes the performance, accessibility, redundancy, security, usability, and a lot of other factors, leaving their mark on the estimation size. Unfortunately, teams often do not determine the client expectations on these factors, instead, relying on assumptions that turn out wrong after showing the created functionality, delaying the implementation.
Definition of Done (DoD)
The non-functional requirements may relate to the application as a whole, affecting all tasks performed in its regard. As such, the requirements should be included in the so-called Definition of Done, a list of criteria that must be met by every task in the project for it to be considered complete.
Working with the Definition of Done benefits the project, as the team has the certainty of what state tasks need to be brought to, thus what the estimation needs to cover. The DoD is established at the very beginning of the project and applies to all executed tasks.
Definition of Done for a XXX Project covers the following points:
✅ A change has been implemented by a developer and is tested locally by him
✅ The written source code has been covered by unit tests and necessary comments (to be verified during code review)
✅ The change meets all the Acceptance Criteria defined in the functional ticket
✅ All commits have been named in a way allowing to generate a meaningful changelog
✅ The created source code has been reviewed and accepted during the code review process by at least 1 technical person
✅ The created source code has been merged into the development branch
✅ The change has been published on the testing environment and made available for the tester
✅ The change is testable – specific configuration and installation is done, the test is performed
Definition of Ready (DoR)
Equally important to the DoD is the Definition of Ready, indicating the task (created in e.g. Jira or Youtrack) is ready for estimation. DoR ensures the team that all estimated (and subsequently, executed) tasks will have the same structure, with all vital information, acceptance criteria, and attachments included.
Definition of Ready for a XXX Project covers the following points:
✅ Ticket title indicates the main goal of the task
✅ The ticket contains a general description of a business goal defined as a User Story
✅ Ticket contains a clear description including a business need explanation (WHY?), the scope of work and expected result of the task (WHAT?) and information about important dependencies, preferred way of implementing the task, limitations, etc. (HOW?)
✅ Ticket contains acceptance criteria as a bullet point list with crucial elements of the task that define its completion (acceptance criteria don’t need to contain requirements included in the general Definition of Done )
✅ All necessary attachments (mockups, external documentation, etc.) are enclosed to the ticket
✅ Estimated time effort is attached (added during planning meeting)
Communication
However cliché it may seem – exchanging ideas, suggestions, and worries prior to delivering the estimation to the client can work wonders. Chances are that there was never time spent on gathering the teams’ feedback that wouldn’t be worth the time spared on fixing possible issues caused by too hastily prepared estimates.
Communication with the client is an important part of the process, and as such, should be executed with diligence. To ensure the best workflow, preferred means of communication should be established. Especially in projects where the client asks the developers directly to modify or add elements, the project manager should take into account possible changes to the estimations’ outcome.
Transparency
Another element that may seem too obvious, but is often overlooked. The client needs to be informed upfront that the estimations can – and as we already mentioned, will – change. Especially in agile environments and time & material projects, alterations are inevitable.
When significant changes occur, all parties involved require updates. While it most probably won’t make clients’ CFO happy to hear that a module will take 10 more days than earlier planned, the project integrity will only benefit from the transparent approach. No matter if the project is going great or something malfunctioned, the client needs to be informed.
More than code
Product development involves several processes, and finishing the code doesn’t mark its end. The final estimation must cover the time and workforce necessary for design, development, testing, deployment, and maintenance. Estimating solely the coding part results in serious disparities between the judged time (and cost) of completion in confrontation with the actual results.
The process requires coming to an agreement with the client on how done is done, to ensure that the delivered work is exactly what’s expected. Taking into account refinement, scrum meetings, discussing endpoints and features extends the projects’ time. Experienced teams and PMs know the general timeframes and can assess the % of time spent on the development, compared to e.g. configurations, tests, and bug fixing.
Sometimes developers tend to lower their estimates to show off their skills and expertise, trying to prove that the tasks in question will be smooth sailing. Others, on the other hand, look for problems where there’s none, aiming at the highest possible estimate to land a safe space, even though the calculation exceeds the real and reasonable timeframes for performing the task.
For the above reasons, all team members need to be aware what’s the purpose of estimations and that it serves the teams’ interests. In short, teams estimate in order to plan better and bite off enough to chew, no more and no less. Overestimating and underestimating impairs the project. Estimating less leads to a decrease in productivity of the team, resulting in under-delivery. Estimating too many tasks upsets the client and the team, as set goals aren’t met. Taking into account the team wellbeing and working towards a greater good pays off in better results. With the right amount of planned tasks, and knowing what’s ahead, developers can work without the unnecessary stress and time pressure, having confidence in their skills and satisfaction from delivering the desired value. The client gains peace, knowing their product is developed in a predictable environment and can continue with planning business operations according to the schedule of expected functionalities.
The buffer or the safety margin
Aside from the described above methods of reducing inaccuracy of estimations, project managers and team members directly involved in the project have one more lifeline. When summarizing estimations delivered by the team, and before presenting the final version to the client, one last factor is brought into the play. The final estimation is usually enhanced by approximately 15-20% to cover the disparities, counteracting their impact on the project. Factors affecting the safety margin cover a properly executed risk analysis for the estimated task or functionality (the greater the risk, the bigger the margin), uncertainty (the less we know about the task ahead, the bigger the margin), the complexity of the task (intuitively – the more elaborate the assignment, the more surprises it may carry).
To estimate or not to estimate?
While estimating is not a miracle cure to all problems in project management and development, it sure helps solve a lot of them. The benefits include building a better relationship with the clients, avoiding financial traps that could possibly disrupt the company’s stability, and naturally, creating products in a well-balanced order.
So what’s the answer? Of course, do estimate. With the utmost care, paying attention to details, and with a healthy dose of realism. Don’t set priorities based on estimations. Instead, estimate based on priorities.
Do you plan to launch a digital product and need to know more about the process? Book your free consultation and find out how we can help it excel.
