Estimation of the time of the project and in the project itself are crucial and significant within agile methodologies (Agile) or, to be more specific, within the Scrum framework.
Estimation of the time of the project in practice means the need to learn about accurate and adequate in terms of the size of the Product Backlog techniques for estimation.
You must remember that project estimation is troublesome and challenging to some degree.
It's not always successful, and the research we will — among other things, of course — write about in this article is a good example.
It's a task that can be accomplished in multiple ways, as the number of techniques developed for its implementation proves.
Among the most described ones, you can find at least a dozen ways that have evident advantages but aren't free of minor or major disadvantages.
Estimating time in a project certainly requires considerable experience and knowledge of how to properly, reliably, and accurately calculate the time needed to deploy or implement a given item from the Product Backlog.
Controlling the course of the project means knowing how much time something can take (optimistic project time estimation) and simultaneously how much time it can't or shouldn't take (pessimistic project time estimation).
Although the time of implementing a given item from Product Backlog depends on many factors — from objective and external to subjective and internal — Product Owners, Scrum Masters, or Scrum teams don't have to rely on pure guesswork.
The more experienced and perfect the scrum teams are in estimating the work required to implement elements from the Product Backlog, the more efficiently and smoothly they run the project.
They can "deliver" it on time and in line with the set schedule, thus staying within the budget.
The ability to predict the necessary time for work is essential if the project is to be entirely successful and in line with the expectations of various stakeholders.
What's even more crucial is that the accurate estimation of the Product Backlog regarding time allows you to prioritize tasks and put them in a broader time context (e.g., related to the number of workdays, planned leaves, or unforeseen situations).
What are the best techniques for estimating the time needed for working on the elements from Product Backlog?
How to make more accurate, justified, and profitable decisions regarding the schedule for digital product creation?
What are the most important benefits of estimating the work regarding Product Backlog?
If you're curious to know the answer, then you need to read this article, in which we'll take a closer look at the issues of estimating work and time.
We cordially invite you to read the article!
Are you looking for a Web Development Company?
Estimation — what is it?
Let's start with fundamental questions: What is estimation? What does it mean to estimate projects carried out in an organization?
What is task duration, and what estimation involves in project management? How to determine the time requirements of the project in the estimation process?
Maybe not every Journal reader knows what the noun "estimation" and the verb derived from it, "estimating," means; thus, let's define it for clarity.
According to the Cambridge Dictionary, "estimation" means "a guess or calculation about the cost, size, value, etc. of something."
Estimation, therefore, shouldn't be confused with the precise determination of quantity. Estimation is never accurate enough to be considered a final, unchanging value.
Estimation is an approximation of the truth, and the degree of its accuracy, that is, compliance with the actual state, depends on many factors.
Factors that are known and those that are imponderable, meaning elements that can't be precisely determined.
Elements that can't be easily and accurately measured or calculated and that are presumed to have a significant impact.
Estimation techniques, the estimation process of individual tasks performed by an entire team, and parametric estimation allow you to make the execution and planning of tasks more rational.
The most significant issues determining the accuracy of estimation include the following:
- Number of historical data
- Completeness of historical data
- Stability of data — the dynamics of their variability over time
- Variety of data
- Value of data — the strength of their influence
- Point of reference — the ability to see analogies
- Experience in estimation
- Understanding of data, contexts, and determinants
- Awareness of most critical risks, variability, and regularity of processes
- Preparation and experience of the team and adopted assumptions — it's vital to accurately define the scope, complexity, and relevance of actions.
In the context of work estimation required to implement a given User Story from the Product Backlog, the estimation means approximating how much time, resources, and specialist is needed to finish it.
It also means adopting specific criteria that will allow you to unambiguously determine whether the implementation of a given functionality is complete.
As a side note, we've written about the Definition of Done (DoD) in a separate article, "Definition of Done - what is it?"
Generally speaking, you can perform estimation in two ways.
In a traditional way which means that you can try to determine the time of the project that is both sufficient and necessary to achieve the desired effect.
In the second case, you can approach the estimation in a relative manner in which you try to see similarities between two tasks and not determine the time.
By comparing known tasks to unknown ones or half-known tasks by determining their complexity and conditions (regarding technology, competencies, or market), you can determine how much time an unknown task but similar to some extent can take.
It's a comparison method that involves seeing analogies and knowing conditions. It owes its accuracy, to a large extent, to experience, knowledge, and precision of adopted assumptions.
Regardless of how you make time estimates, any estimation method should be first and foremost:
- Easily accessible — it shouldn't involve using, for example, expensive tools, techniques, or methods
- Simple and quick to perform
- As cheap as possible — in terms of the cost of the time of the people performing it
- Compelling through simplicity, effectiveness, intuitiveness, and accuracy — it should provide a "hard" sense that its use is right and useful and involves little risk.
While performing the estimation of the work on Product Backlog elements, it's also worth considering the rules described by Vibhuti Verma in the article "How to estimate an Agile Backlog?"
Vibhuti Verma rightly recommends that within agile methodologies, the estimation of working time should be based on putting:
- Speed over accuracy
- Consensuality over arbitrariness
- Relativity over absoluteness.
You should be able to get estimates quickly, even at the cost of accuracy, because the goal is not to obtain certainty but to structure the project in time.
Evaluation should be the result of teamwork and be a sort of common sense; thus, it should be reasonable and have the full support of team members.
A collective consensus is much more accurate or at least more resilient to personal preferences, experiences, biases, or unconscious assumptions.
You should remember that, especially since it protects you from making mistakes of varying degrees of importance.
The relativity of estimation is supported by the natural human need to compare and determine proportions, indicate differences and similarities, and see analogies.
Relative estimation is a constant characteristic of human operation in reality. It's a natural ability that can be used to estimate working time.
Especially since our species has evolutionarily developed a very effective method of collective problem-solving that is much more effective than solutions offered by individuals.
Pattern recognition has allowed humans to gradually subjugate reality.
Comparing two similar things and seeing their similarity and differences comes to us with great ease, particularly when "collective wisdom" is activated.
Estimating the time required to create something is no exception.
The effect also depends on statistical regularities.
Even if the group is not homogeneous in terms of skills, competencies, experiences, and potentials, then at the right scale, the errors of individuals that occur won't affect the quality of the decision made by the group. Their influence will be suppressed.
For example, by knowing who performs a given work, their competencies and experience, and their efficiency, you can estimate how quickly/slowly they will complete a task and if it will be seen as easy/difficult.
It's also worth considering factors influencing the complexity of work that Manuel Küblböck described in the article "How to estimate backlog items."
According to Küblböck's approach, the complexity of an element is primarily influenced by the following:
- Number of people needed to complete the work
- Differentiation of necessary competencies
- Number and complexity of dependencies, connections of the given Product Backlog element with other items
- The team's ability to "handle" dependencies — the work is more work-consuming when it has to be based on "outsourcing of competencies and experiences"
- Number of components required to complete a given task
- Technical debt and the necessity of fixing it
- Availability of test data
- Number and complexity of the interconnectedness of the other work that will be performed during a specific Sprint
- Amount, importance, and influence of unseen, unconscious factors, which, however, affect the speed, quality, trouble-free, error-free, and flawlessness of the work performed.
It is also worth adding that the more similar two things are compared to each other, the easier it is to compare them.
Estimating the work of Product Backlog elements that are largely similar to each other will be much simpler, more accurate, and less prone to errors.
How to estimate the work on elements of the Product Backlog?
Accuracy and usefulness of estimation is, what's obvious, a priority and a troublesome issue.
However, it's worth considering, a little half-jokingly half-seriously, that according to Hofstadter's law, the result obtained, whether quantitatively or qualitatively expressed, will always be underestimated in some way.
As a reminder, Hofstadter's law states, "It always takes longer than you expect, even when you take into account Hofstadter's Law."
It was presented in the book "Gödel, Escher, Bach: An Eternal Golden Braid," and it shows that estimation accuracy is always more or less problematic.
Hence, it can't be treated as an absolute value but rather as a kind of signpost, a hint.
Hofstadter's law is not just an intellectual curiosity, a kind of intellectual joke, but is observable in the daily work of scrum teams.
Studies also confirm it.
A study by McKinsey and the BT Center for Major Program Management at Oxford University found that as many as 66% of software projects experienced cost overruns.
What's even worse, according to the McKinsey study conducted with the BT Center, in 17% of IT projects, underestimations nearly caused companies to fail.
On average, large IT projects go over budget by 45%, yielding 56% less value than expected.
This study was conducted on over 5400 IT projects, which ensures the reliability and accuracy of these results. McKinsey and BT Center for Major Program Management research regarding the methodology is very credible.
Not surprisingly, the accuracy of estimating the work on Product Backlog elements should be improved.
The scope, complexity, typicality/uncommonness of the project, scope changes occurring during subsequent Sprints, and missing functionalities are most often responsible for exceeding the estimated implementation time.
Furthermore, the "culprit" is also the tendency of people to overestimate their own capabilities, resulting in underestimating the time required to complete a given task, to achieve a given goal.
In psychology, this tendency is called Illusory Superiority, which comes to the fore when estimating the difficulty of tasks.
Appealing to common sense that is more protected by a group and not individuals allows you to avoid these effects of underestimating and plan work more flexibly.
Hence, the Product Backlog should be maximally accessible, clear, and organized according to the consensually established order by the development team.
A way to deal with underestimation is also to divide the project into Milestones, which set the time frame for the project. Dividing large tasks into smaller ones and those into even smaller ones also helps achieve better precision and more accurate estimation.
Even such "makeshift" structuring of a project's time allows you to make better, more adequate, and effective decisions.
However, the real game changers in this topic are the popular techniques for estimating the work of Product Backlog elements in agile methodologies.
A dozen are most often discussed in the subject literature. We've selected a few of them that, in our humble opinion, are certainly worth using.
The selection of a specific technique should always be a matter of the character of a given project, the size of the Product Backlog, the nature of tasks, and the experience of the team.
Fibonacci Sequence
Fibonacci Sequence is formed when each successive number is the sum of the previous two. For instance: 1, 2, 3, 5, 8, 13, 21... And as such is a perfect comparative scale.
Fibonacci Sequence is used to determine the size of a given task. It's enough to assign a specific numerical value to a particular task, which represents the time, effort, difficulty, and complexity required to complete it.
In practice, a range from 1 to 21 is most often used to determine the level of difficulty. With a certain starting point, each subsequent similar Backlog item can be estimated by comparison to the initial task.
Fibonacci Sequence highlights the distances separating successive positions as the complexity increases. Note that between the 21 value and the next one, 34 is a gap of 13 points, while the distance between 21 and the previous 13 is only 8 points.
Thus, simple tasks that are similar to each other will differ little in the value you assign to them. Which in turn helps obtain more realistic estimations.
T-shirt Sizing
Everybody is familiar with the sizing of shirts. They can be Extra-Small (XS), Small (S), Medium (M), Large (L), and Extra-Large (XL).
You can intuitively and seamlessly "capture" their differences and what they mean in practice. The metaphor of the T-shirt as the size of the project is both highly illustrative and, in a good way, peculiar. It is also accessible to everyone.
As a result, the sizes can be very accurate measures of the level of complexity and the difficulty of the User Story, for which estimation is most often used.
After the facilitator reads the User Story, the scrum team assigns a size to it and, through discussion, determines the t-shirt size that best fits it.
The advantage of this method is that it operates with qualitative quantities (although some consider this to be a disadvantage, mainly due to lower precision) that are illustrative and linked to experience.
Playing Cards
Every scrum team member receives a deck of cards in this estimation technique. Each deck represents a specific value derived from the adopted scale.
The facilitator reads out User Stories with their acceptance criteria. All team members evaluate their level of difficulty and complexity with the help of raised cards.
The team's goal is to discuss ratings, especially the extremes, relating to minimum and maximum difficulty levels and reach a consensus.
This method is recommended for Product Backlogs containing a small number of items (no more than a dozen) because the essence of this technique is analysis, discussion, and consensus, which take a lot of time.
Program Evaluation and Review Technique (PERT)
Employees of the United States Department of Defense developed this technique.
The project being evaluated is represented by a network diagram, the vertices of which correspond to tasks, and the lines connecting them indicate their interrelation along with the estimated duration.
The core of this technique is to treat the duration of a task as a random variable rather than determined by specific factors. Thus, it is possible to calculate statistical probability.
Three variables are taken into account in the calculation:
- Optimistic Time — minimal amount of time needed to complete a task
- Most Likely Time — the most probable time required to complete a task
- Pessimistic Time — the maximal time necessary to complete a task.
The Time Expected is calculated using the formula: TE=(O+4M+P)÷6.
The speed and ease of calculation are significant advantages of this technique. In contrast, the biggest disadvantages include the subjectivity of assigning time values to tasks and the excessive rigidity that results from thinking about the network in a deterministic way.
Program Evaluation and Review Technique is a recommended method for estimating the working time of a significant number of items in the Product Backlog.
How to estimate your Backlog? Summary
- The words estimate and estimating mean determining the value or size of something approximately.
- Estimation is a somewhat approximation to the truth.
- Relative estimation is a constant characteristic of human operation in reality. It's a natural ability that can be used to estimate working time.
- The level of accuracy of the estimation, and therefore compliance with the actual state, depends on a number of factors. Both known and unknown/unconscious.
- Remember, every estimation is imperfect. According to Hofstadter's law, the result obtained, whether quantitatively or qualitatively expressed, will always be underestimated in some way.
- Estimation can be carried out in a traditional way, trying to determine the amount of time that is both sufficient and necessary to achieve the desired effect, and in a relative way, in which you don't so much try to indicate the amount of time but to see the similarities of two tasks.
- By comparing known tasks to unknown ones or half-known tasks by determining their complexity and conditions, you can determine how much time an unknown task but similar to some extent, can take.
- Estimation of the time of the project in practice means the need to learn about accurate and adequate in terms of the size of the Product Backlog techniques for estimation.
- Estimating time in a project requires experience and knowledge of how to properly, reliably, and accurately calculate the time needed to deploy or implement a given item from the Product Backlog.
- Accurate estimation of the Product Backlog in terms of time helps prioritize tasks and set them in a broader time context.
- Evaluation of the Product Backlog elements should result from teamwork and be a sort of common sense; thus, it should be reasonable and have the full support of team members.
- The scope, complexity, typicality/uncommonness of the project, scope changes occurring during subsequent Sprints, and missing functionalities are most often responsible for exceeding the estimated implementation time.
