“We will deliver on X. Promise!”
People are inherently bad at estimating how much time is required to complete any kind of task. However, managers want some sort of outlook on how much the team can deliver in a certain time – when will the stuff be ready?
So how do Agile teams know when will they deliver something? The solution is – to calculate the time instead of guessing it! That is done by using estimations (to #estimates traditionalists) OR by actively not using estimations (to all #noestimates fans) which is an activity itself.
Using the #estimates approach
Many Agile teams use estimation techniques to calculate the time required for completing some work.
Estimating the work
To calculate at what time you will arrive at your destination – you have to know the distance to be travelled and the average speed of your vehicle:
Time = Distance / Speed
To apply the same formulae to teamwork and calculate ‘when stuff will be done’, you need to somehow express the ‘Distance’ concerning the work at hand and the average ‘Speed’ of your team. Distance is the total amount of work to be done – and it has to be quantified. Naturally, teams have several tasks at hand but the number of tasks is similar to the number of streets that the car has to drive – it does not describe the length of the streets.
Since the team cannot guess the time it’ll take to complete the tasks – it has to attempt to assess other qualities of the tasks. Agile teams usually assess three parameters and those are always assessed in comparison to some reference task agreed upon by the team:
- Effort – how much more/ less/ the same effort will be needed to complete the task compared to the reference task?
- Complexity – how much more/ less/ the same complex this task is compared to the reference task?
- Risks – is this task the same/ more/ less risky than the reference task?
So if a reference task has been assigned value X, then the task that is estimated can be awarded a value of X (the same) or X + 1, 2, 3, n (more effort/ complexity/ risk than the reference task) or X – 1, 2, 3, n (less effort/ complexity /risk than the reference task). In this way, the team can agree to assign specific estimates to all the tasks. These values are often referred to as ‘points’ (or ‘story points’) and the team discussion during which the points are assigned is called ‘estimation’. Of course, the team is using their experience, best judgment, all the information available, and their gut feeling to guesstimate if the task is more or less complex/ requires more or less effort/ is more or less risky. But doing this consistently for all the tasks establishes a good practice and a standardized process in which all tasks are treated equally.
All estimates combined show the total ‘distance’ to be travelled – the total workload that the team has to complete. The estimation value in points is fixed for all tasks and normally does not change over time – just like the distance in kilometres between Berlin and Paris doesn’t change that much regardless of who’s driving.
The velocity of a team is the same as the speed of a car – it can be calculated.
The average speed of a car is expressed as a certain distance the car can travel within fixed period of time – such as 50 km/h. Now, Agile teams similarly work in fixed time iterations. But those are longer than 1 hour – such as 1 week, 2 weeks, or 4 weeks. In this way the average speed of an Agile team is the amount of work expressed in the aforementioned points that the team on average completes in the chosen fixed period of time. The most frequently used time iteration for Agile teams is 2 weeks and teams that apply the most popular Agile framework ‘Scrum’ call these time iterations ‘Sprints’.
Therefore, the speed of the team can be described as X points per Sprint where sprint can be any chosen (by the team) fixed iteration of time. The speed of the teams is often referred to as the ‘velocity’ of the team:
Velocity = Points / Sprint
The average velocity of a team can be established over the time. It cannot be judged by 1 or 2 Sprints because the team and the team members will inevitably change over the time. It is common to use the data from the last 5-10 Sprints to establish average velocity.
Calculating the time
Now that the team has estimated and assigned the number of points (describing complexity, effort, & risk) for all work to be completed to reach a certain objective and the team knows its average velocity – it is easy to calculate how much time will be needed to complete the work.
Time to complete work = Points to be completed / Average velocity
The good news – this calculation can be done by anyone. Product Managers can use it to calculate when the team may complete certain portions of work and in this way provide a much more intelligent response to the daunting question of “When stuff will be done?”.
Using #noestimates approach
The recent #noestimates movement suggests that estimation is not really a value-adding activity and can put unnecessary pressure on the team for staying within the original estimate. Indeed, the estimation techniques are complex and require time to master. Therefore, it is often recommended for Agile teams to skip the estimation exercise described above entirely.
#noestimates still require estimation
The management will keep asking the same type of daunting questions (“When stuff will be ready?”) regardless of what estimation or no-estimation approach you choose. How to provide an educated answer without estimating? The alternative solution still requires some extra effort: becoming an expert in slicing tasks. The team has to learn to split the tasks into chunks that are equally time-consuming. Thereby, Task B should be sized/ sliced/ shaped to take the same time as Task A, Task C, and Task D. As Agile teams mature, they will potentially become better at slicing tasks consistently.
When the backlog of tasks consists of equally sliced chunks and one knows how much time on average it takes to complete a task – it’s a simple math of multiplying the number of pending tasks (to deliver a certain work product) with the average time it takes to complete a single task by the team:
Time = Number of tasks x Average time it takes to complete a task
A word of advice…
Knowing that people are bad at guessing how much time they’ll need to complete any work, managers should never ask the teams to provide such guesses. There are good techniques that are tested and proven by Agile teams over time – those can be used to get all the data necessary to be able to calculate how much time will be needed to deliver.
Don’t ask when – calculate it!
