What is software project estimation?
Estimation is the measured complexity of task implementation expressed by a value. The values can be traditional – hours or man-hours, and non-traditional – Story points, T-shirt sizes, a difficulty scale.
Agile uses several unconventional (abstract) meanings. The abstract values from Agile project assessments have different methodologies and approaches for obtaining the final estimates of project complexity.
Why do teams estimate in Agile?
Overestimation and underestimation are both common in Agile software development companies. As a result, development and launch times vary. Consideration of Agile estimates in the early stages can help with effective user story estimation. It keeps the team focused on the deliverables and prevents distraction.
Here are some of the most important advantages of Agile estimation techniques.
Better decision-making
The development team can conduct practical backlog grooming sessions with accurate agile estimating, which will aid in sprint planning. This will allow developers to make informed decisions and plan their strategy more precisely, so their user story delivery time will improve.
Improved coordination
Let’s say the estimation effort for user story A is projected to be two weeks. The estimation effort for user narrative B, on the other hand, is four weeks. Both user stories are now interdependent and linked. Because of that, the team must prioritise tasks so that both user stories are completed concurrently. That initial challenge will result in better team coordination.
Better risk management
Budgets and schedules for software projects are frequently exceeded. Agile project estimating is an excellent way to mitigate the risk of that happening. The practice assists in estimating story points and adhering to budgets, requirements, and the scope of the project – the more precise the estimates, the higher the chances of on-time, quality delivery.
Agile estimation pitfalls
However, there are also some pitfalls in the Agile estimation process.
Uncertainties are not taken into consideration.
Agile estimates are often criticised for their inability to account for hazards, regardless of the estimation approach or measuring unit used. After all the difficulty of future tasks might range greatly.
Estimates cannot be considered final.
The most significant limitation of estimates is the assumption that once work is measured, it is final. You should always be ready to take care of unexpected factors.
Estimation errors.
It’s not uncommon for teams to get carried away with the agreed-upon estimates, mistaking them for guaranteed numbers they can use as basis for assigning particular timetables or grading team members. It’s a counter-productive and demotivating practice.
When does project estimation happen?
Before we start describing the methods for estimating labor costs in an Agile project, let’s talk about what it is for and what it affects. Let’s try to look at the topic of the article through the eyes of the project client.
Any project has several stages of development:
- Start – the idea of creating a new product
- Estimation – this includes a full evaluation for the implementation of the project, but we will focus on the issue of estimating labor costs and how they affect the other stages
- Planning – it is believed that by having an estimate, we can plan out some of the terms for certain stages of the project. For example:
- Development start
- Iterations planning
- MVP product release
- Performance – the start and the end of project development
- Completion – the delivery of the finished project to the customer
In the above-mentioned step-by-step structure, software project estimation – of labor costs, in this case – plays an extremely important role since it directly affects Planning, which in turn affects the Performance phase.
Consequently, an incorrect estimation will eventually lead to non-adherence to the project development plans, which will throw the project back to the estimation stage because of the need to re-estimate the tasks.
This is a normal practice for short distances in flexible methodologies like Agile, and a very bad one when it comes to classical development methodologies where the project price and implementation plans are fixed and secured by contractual obligations – it implies significant losses of both time and finance.
Interestingly, the Estimation phase itself, which is the pre-planning stage, is very dependent on it. The choice of assessment methods and their values depends on what type of planning is used in our project. For example:
- Planning from the beginning of the project. In this case, we take all the necessary scope of the planned work and schedule it according to the plan. Then, as the work progresses, we make plans for the completion of each stage. It’s a fairly popular approach when it comes to tasks that are similar in complexity and volume, but the disadvantage of it is that by the end of the schedule it might turn out that 40% of the work has not been completed, and you only have two days left for its implementation.
- Short-term planning. We’re not talking about planning for the entire project (although there is always an outline for the completion of work or a roadmap in iterative projects), but about planning for a short foreseeable time period within one to two weeks. This approach is used in Agile and is consistent with the Agile evaluation principles.
The software project estimation methods that we will talk about today are related to the second type of planning since it is most often used in software development.
We help our potential clients understand that this planning method helps to reduce the risks of missing deadlines, since the relation between the current state of the project and the one planned in the roadmap is monitored with enviable consistency. This allows you to quickly focus on individual labor-intensive tasks and to reallocate resources according to the project requirements.
And just like that, we’ve reached the Estimation stage.
Our Technical Team Lead Alexey Shinkarev shared his thoughts about project estimation:
Without any experience, it’s almost impossible to give clients an explicit estimation of a project. It’s very important to look through the portfolio of a development company to find something similar to what you want. That way the estimate will be closer to reality. However, do not focus only on the projects that almost duplicate your idea. There is no point in creating a solution that already exists. Another issue is that the estimation manager has to be in touch with the development team during the estimation process. The view from both sides makes the estimation more accurate.
The discovery phase and pre-development are the two stages without which the estimation is almost impossible. The discovery stage lasts about 1-2 months and the results of the work done during this stage are user flow, user stories map, wireframes, and diagrams showing integration logic. User stories map is a key element that comes from this stage and helps in estimation.
The pre-development stage involves developers practically checking all possible integrations, trying to find pitfalls, asking a lot of uncomfortable questions about the logic, and doing everything possible to bring the estimation as close to reality as possible. However, it is not at all guaranteed that some unforeseen problems will not arise later and the estimation will not have to be revised. The manager’s task is to constantly be in touch with the development team and broadcast information to clients or superiors as soon as possible, as openly as possible so that trouble does not occur.
What are story points and how to estimate them?
Story points are Agile product development metrics. They are used to calculate the amount of effort required to complete a product backlog item. These are assigned based on the task’s complexity, uncertainty, and amount. They also help to ease the process of designing a strong implementation strategy and determining an item’s ROI.
When estimating story points, developers must consider three variables:
- The feature’s complexity;
- The danger of unforeseen changes, ambiguous requests, reliance on third parties, and other unknowns;
- The team members’ understanding of the feature.
The following steps can help you estimate story points more accurately:
- Determine user stories.
- Talk about user story requirements. The Product Owner or Business Analyst is in charge of addressing queries and clarifying what the referred story involves.
- Create an estimating matrix. This matrix is a numerical scale that aids in the evaluation of the task’s selected components. You can use the Fibonacci sequence or the linear scale for that. The Fibonacci sequence is used more frequently by software teams because its gaps are wider than those in a linear scale.
- Choose an appropriate estimation technique.
- Carry out sprint planning to determine which stories will be estimated and prioritised.
- As you continue, make sure the estimations are consistent and fit with the user stories.
What is sprint velocity and how to estimate it?
Sprint velocity is the rate of work of an individual team during an average sprint. In other words, it’s the number of story points that a certain team can complete during a sprint. Unfortunately, until the first sprint is completed, there is no way to estimate sprint velocity.
However, future velocity can be forecast by looking at the team’s past data (for example, keeping note of how many story points were finished in a prior sprint). You can first calculate the sum of the number of finished story points and the team’s actual velocity during a sprint. The resulting data will aid in determining the number of sprint cycles required to complete the project.
Why you need software project estimation?
The need for a software project estimation appears when the client has provided a list of features for the team to implement, with each task having an assigned priority. This is a laborious process where the entire development team (here, for the sake of the most efficient result, I mean everyone working on the project: designers, testers, etc.) must reach a consensus and determine the complexity of a particular task. The estimation will allow the team to see the likelihood of finishing the assigned tasks within a certain time period – for example, Sprint.
Before talking about the Agile estimation techniques, it is worth mentioning the principles of software project estimation as a whole. This will allow you to better understand the methods themselves and the logic behind their application.
Agile estimation techniques: main principles
| High estimation speed | Agile implies a high speed of delivery of the product to the customer with quick feedback for reconfiguring plans if necessary. Agile estimation should be fast and effortless, since it does not bring any business value to the project. |
| Teamwork | Agile is committed to teamwork, and estimation is done with the maximum involvement of every team member. It is important to get the opinions of all the team experts. If we are talking about Scrum teams, then all members will take part in the estimation of the Backlog, regardless of their role and level of competence. Software project estimation in a team allows you to openly express your opinion which results in drawing a more objective, realistic picture. |
| Abstract (unconventional) units | Using unconventional values allows you to estimate tasks in an open-minded way, avoiding tying the estimates to the notions of time and cost. Tasks can be compared exclusively with each other in terms of their implementation complexity. Agile estimation can be carried out using any value (Size, Story points, or buckets), but the lowest value for estimation will always be equated to the easiest task in the opinion of the team. For example, 1 story point can be equal to the development of a text field. |
Which techniques of software project estimation can be used in Agile?
1. Planning Poker
What is Planning Poker
Being one of the most popular Agile story point estimation techniques, Planning Poker is based on the use of scores to reflect the complexity of the task. The base is the Fibonacci numbers 0, 1, 2, 3, 5, 8, 13, 20, 40, and 100, which are plotted on cards similar to those used to play popular card games.
How to use Planning Poker
The principle is that each team member receives a deck of cards with a list of points and gives his evaluation of the task after all the clarifications and discussions on its implementation.
- The members receive cards.
- They discuss the task and its nuances.
- Each member of the team chooses – in his opinion – the most suitable value for the task’s complexity. Then, he puts it on the table face down, so that the teammates can’t see the selected grade and don’t have their opinions swayed.
- When all members of the team have evaluated the task, they simultaneously flip their cards, rating up.
- Those who have selected the lowest and the highest scores explain their choices.
- An average rating is decided, or, based on the comments of members of the team, a re-voting is carried out from the previous step to reduce the results to the lowest possible rating spread.
Nowadays, Planning Poker is one of the most popular methods of estimating tasks in Agile, due to its ability to quickly and accurately determine the difficulty of a problem.
The downside of Planning Poker is its ineffectiveness in large teams and in the estimation of heavy tasks. Therefore, many teams have an agreement that a task that has received a certain high score should be decomposed and its subtasks should be evaluated separately.
2. T-Shirt Sizes
What is T-Shirt Sizes
The T-shirt Sizes is an Agile Story point estimation technique based on the clothing sizing system. There a variety of sizes exists, starting from the smallest XS to the largest XL, with S, M and L sitting in-between. Each of the abovementioned sizes is equated to the complexity level of a certain task.
How to use T-Shirt Sizes
The key to using this technique is a quick discussion of ways to achieve success in development and subsequent evaluation.
- Product Owner opens the discussion of the story (feature) to be estimated with the development team.
- Each member of the team designates the appropriate T-shirt size (degree of difficulty) to the story (feature).
- The members of the team explain their decision and discuss the differences if any. The Product Owner provides any additional clarification when needed.
- After one final discussion, the team arrives at a unified T-shirt size for a specific story.
- All the estimated stories are allocated between size buckets.
- Finally, the team can estimate the time to complete all stories in S, M, L, XL buckets.
This method is very good for quick and rough Agile estimation of a software project, but it may create precision problems due to the rather narrow range of the estimation base, namely the sizes of the T-shirts themselves.
3. Dot Voting
What is Dot Voting
Dot Voting is the visual result of the Agile estimation concerning the priority of the task. It allows the team to see the whole picture for the entire set of tasks by using a number of points (markers).
How to use Dot Voting
The main idea behind this Agile estimation technique lies in giving public access to all the required tasks and the ability of team members to sequentially define tasks by their complexity using a limited set of points.
- The leader lays out the necessary set of tasks on a board (each task is described on a separate sticker, with the stickers being organized by priority: for example, from left to right – from highest to lowest priority)
- Each member of the team is given a limited number of dots (or the ability to indicate them with a marker)
- Each team member comes up to the board and distributes the points according to the complexity of the tasks: for example, an employee has 5 points for three tasks. They will put one dot under the first (highest priority), three dots under the second (medium priority), and the last remaining dot under the third with the lowest priority.
- The team leader rearranges the tasks (stickers) in accordance with the complexity of the tasks, and not by priority, and the team decides on which task will be the best to start the sprint with.
It’s an effective method when the number of tasks is small, and works great for their visual analysis. But it’s not the most reliable method of assessment, as it is very superficial and serves as more of a tool for deciding the order of tasks in a sprint.
4. Ordering Rule
What is Ordering Rule
Ordering Rule is a game estimation technique that involves the interaction of all members of the team; it aims at equating a set of tasks to a difficulty scale. The scale reflects the complexity of the task and has a minimum initial value and a maximum final value in terms of labor intensity. Intermediate difficulty segments are set between the lowest and ultimate values.
How to use Ordering Rule
- The team leader randomly distributes all the necessary tasks on a rating scale
- Each team member takes turns doing one of the permitted actions:
- move one task left or right by a single increment
- discuss the task with colleagues and ask the necessary questions about its implementation
- skip the turn
- The estimation of the tasks is finished when all of the colleagues skip their turns, indicating that they agree with the achieved estimation for all the tasks.
This technique leads the team to a fairly high indicator of the quality of the estimation of tasks, but it takes a long time to implement, and is, therefore, only suitable for a small number of tasks per meeting.
5. The Bucket
What is the Bucket
The manager uses this strategy to establish a number of buckets, or categories, which are represented by pieces of paper. Each bucket is labelled with a number that corresponds to the level of complexity or time necessary for project tasks. Longer and more difficult jobs are assigned to higher-numbered buckets, while shorter and easier activities are assigned to lower-numbered buckets.
How to use the Bucket
The manager starts by placing one assignment, commonly written on a sticky note, in a bucket based on its estimated duration or difficulty. Participants give jobs to different buckets, with the purpose of each bucket containing comparable tasks. Teams may discuss each task as it is completed or wait until all chores are placed in the bucket. The assignment is completed when all tasks have been assigned to buckets and the team has had adequate time to discuss each one.
6. Three-Point
What is Three-Point
The three-point estimate technique was developed in response to the inaccuracy issues caused by committing to a specific estimate before any work began.
Estimates can become unreasonable when you get caught in the trap of thinking that because you did well previously, you would be able to do it again. In reality, there’s no solid guarantee of that, even if the same team is working on the same type of job.
How to use Three-Point
The three-point estimate technique has you assigning three time values to each task:
- Most likely;
- Optimistic;
- Pessimistic.
For example, the three expected time values for Activity A are as follows:
- Optimistic (o) = 5 hours
- Most likely (m) = 10 hours
- Pessimistic (p) = 20 hours
We may estimate the general expected time by calculating the mean:
E = (5+10+20 ) / 3 = 11.7 hours
7. Fibonacci Sequence
What is the Fibonacci Sequence
The Fibonacci sequence is commonly used as a scoring scale by most teams. This linear sequence is made up of the sum of the two previous integers in the series – 0, 1, 1, 2, 3, 5, 8, 13, 21, 34, 55, 89, and so on.
How to use the Fibonacci Sequence
Looking at a story and judging if it is an 8 or a 13 makes it easier and faster to come up with an answer. Furthermore, the team reaches a decision more quickly.
When estimating huge and complex projects, the Fibonacci Sequence approach is useful since it prevents estimates from being too close to one another.
8. Top-Down
What is Top-Down
Top-down estimating is a project management technique used to estimate the cost or duration of a project by starting with a high-level view and then breaking it down into smaller components. This approach is often used when there is limited information available about the project, such as in the early stages of planning.
How to use Top-Down
To use top-down estimating, project managers will first identify the major components of the project. They will then estimate the cost or duration of each component, based on their experience and knowledge of similar projects. Once the estimates for each component have been calculated, they are added together to get an overall estimate for the project.
Here are the steps on how to use top-down estimating:
- Identify the major components of the project. This includes all of the tasks, activities, and deliverables that need to be completed in order to finish the project.
- Estimate the cost or duration of each component. This can be done based on the project manager’s experience, knowledge of similar projects, or historical data.
- Add the estimates for each component together to get an overall estimate for the project.
9. Bottom-Up
What is Bottom-Up
Bottom-up estimating breaks the project down into smaller, more manageable tasks. This approach is often used when there is a lot of information available about the project, such as in the later stages of planning.
How to use Bottom-Up
To use bottom-up estimating, project managers will first identify all of the tasks that need to be completed in order to finish the project. Then, based on the experience and knowledge of tasks alike, they will estimate the cost of each task. Once estimation is done, the results are summed up to get the overall project estimation.
Here are the steps on how to use bottom-up estimating:
- Identify all of the tasks that need to be completed in order to finish the project.
- Estimate the cost or duration of each task. You can do it by relying on the project manager’s experience, previous similar tasks, or other previous data.
- Sum up the individual task estimates and get the total estimation of the project.
Best practices for Agile estimation
As in any other process, there are some best practices for Agile estimation you can follow to achieve better results.
Start with smaller stories
Smaller stories are considerably easier to estimate than big epics. Pick the low-hanging fruit first. It will assist your team in becoming acquainted with the estimating process, increasing your chances of producing accurate agile estimates.
Break down epics
You can also break epics up into smaller chunks if they are too difficult to complete in one go. This allows you to generate precise estimations with less effort. Smaller epics also allow you to better plan your sprints.
Use an iterative estimation approach
Traditional projects can be easily estimated 2-3 times. Agile estimation, on the other hand, does not work in the same way. It is far smarter to take a participatory approach and assess software development estimates at each new sprint. This allows teams to better grasp the estimation process and simply divide large projects into smaller ones.
Be a part of the team
Agile estimating is a team sport in which active communication and teamwork are required. When everyone on your team is involved, you can better forecast the time and effort required to finish a project. It also fosters active engagement among your team members because everyone feels accountable for their efforts.
Involve subject matter experts in the agile estimate process as well. They may provide valuable guidance and help you achieve more accurate estimates.
Use previous data
Historical or industrial data is essential in agile estimation. Approaches to projects evolve, and new methods arise constantly. Nonetheless, decades-old studies remain relevant and can help you navigate difficult situations.
Make sure you refer to them while estimating projects. You might get a surprising new idea on how to improve your agile project estimations.
Conclusion
Although we haven’t touched on every method currently out there, but these four are the most popular ways of estimating Agile projects. Since every team following the Agile framework has its own workflow specifics, flexible methodologies allow you to combine and change Agile estimation techniques in order to achieve the best possible end result.
