- When does project estimation happen?
- What is software project estimation?
- Why you need software project estimation?
- Agile estimation techniques: main principles
- Which techniques of software project estimation can be used in Agile?
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.
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 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 inbetween. 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.
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.