A different kind of effort estimation
A fresh perspective on effort estimation in software development
In the agile world of software development, teams are often faced with estimating the amount of work required to develop new features. These estimates serve as the foundation for planning sprints. However, experience shows that the actual effort regularly deviates from the original estimates – and usually upwards. Some tasks are underestimated due to naivety or the pressure to submit low estimates, which leads to a mismatch between the estimate and the actual effort. The gradual expansion of the project in response to new requirements or emerging difficulties can also lead to an increase in workload. And, of course, the technical implementation can bring unforeseen problems and difficulties that were not included in the original estimates.
In short, the causes are complex and reflect the complexity and unpredictability of software projects.¹
In addition to the inaccuracy of the estimates, the estimation process itself, such as the evaluation with story points, sometimes generates considerable additional effort that should not be neglected.
So what can organisations that deal with the topic of effort estimation in software development do?
The approach without estimates
One conceivable solution to this problem is the so-called #noestimates approach. This involves dispensing with the estimation of work packages in story points and instead breaking tasks down into equally sized subtasks, the number of which can be recorded directly. The total number of these subtasks then serves as a measure of the workload. A pleasant side effect is that teams learn to organise and understand complex tasks into manageable units.
But is this the solution?
Effort estimation – why?
Why do we invest effort in effort estimates at all? The most common reasons are:
Sprint planning: the idea of defining tasks based on story point estimates for the sprint scope and committing to fulfil them seems questionable to me. I am convinced that an efficient team will do everything in its power to achieve the maximum anyway. Should this not succeed, there are valid reasons that cannot be solved simply by committing in advance to fulfil a certain scope. In general, the value of such a commitment is low if most estimates are not met anyway. It is unnecessary to spend energy pretending that this is feasible.
Optimisation of velocity: Another argument for effort estimation is the measurement and optimisation of team productivity. Although a team can develop quickly, dependencies or complexities recognised late can cause the overall effort (or duration) to increase significantly and not reach the planned scope. To measure productivity, there are simpler methods and tools that automatically determine productivity metrics directly from version control (e.g. GitHub) or task management data (e.g. Jira).
When are which effort estimates actually useful?
So are effort estimates completely superfluous? Not at all! There is a valid reason for carrying them out: the prioritisation and planning of projects.
In product development, it is necessary to prioritise various undertakings. This is almost always the case, as there are typically numerous ideas, feature requests and long backlogs, but only limited resources for implementation. For effective planning, it is important to compare several aspects: the expected benefits and the necessary effort.
Information about dependencies required for the implementation of the project, such as the point at which another team must provide a certain service, is also crucial for successful planning.
Effort estimates are therefore essential for prioritising and planning projects, albeit not at sprint level, but primarily for a rough estimate of the effort required for milestones and overall implementation.
How can these efforts be easily estimated?
Pragmatic T-shirt sizes
A practical method for estimating effort is to use T-shirt sizes. Sizes such as S, M and L are used to roughly classify the effort. Beforehand, you define what the sizes mean in terms of effort, for example
- S: 1-2 team weeks
- M: 3-6 team weeks
- L: 7-12 team weeks
This system can be expanded to include sizes such as XS or XL if required, but you should not exaggerate here to avoid giving the impression of accuracy that is not actually the case.
With such a definition, a team can estimate undertakings very quickly.
Transparency in the event of uncertainties
When planning projects in particular, it can be necessary to be as precise as possible in terms of time. Agile methods rightly point out that it is difficult to accurately predict the effort involved – especially for large projects that are far in the future. These uncertainties should be taken into account in the estimates by specifying time periods instead of concrete durations that reflect the potential uncertainties. An example would be an estimated realisation period for a project of 2 to 6 months. And if there is uncertainty, the range should be this high.
Final thoughts
Effort estimates at sprint level are not very effective. There are also more effective methods for the optimisation of team speed.
However, effort estimates are important and useful for prioritising overall projects, which can be done with minimal effort using T-shirt sizes. For detailed time planning of large projects, it is advisable to make the uncertainty of estimates transparent by specifying time ranges.
The #noestimates approach, on the other hand, remains a valuable approach in the sprint, as it ensures that all tasks are broken down to a comparable size and thus better understood.
Extra bonus
Here you will find 3 additional questions on effort estimates answered by Jan Hegewald (please press plus):
What happens to work packages that are smaller than the smallest T-shirt size?
Jan Hegewald: Of course, you could also introduce T-shirt sizes XS or even XXS. However, this raises the question of whether it wouldn’t be more efficient to implement the work package directly instead of wasting time with a cost estimate. The answer depends on what this estimate is needed for. If you are estimating a larger project in order to prioritise it, and the work package is one of many, then I would recommend not breaking the work package down and instead estimating it together with another work package.
How useful is it to relate the scope of T-shirt sizes to the agreed project duration?
Jan Hegewald: There are certainly projects with tough time requirements, e.g. when implementing regulatory requirements, but from my point of view you can only derive an approximate project duration from a effort estimate. And since the effort estimate leads to the approximate project duration, it makes no sense to adjust the scope of the T-shirt sizes in any way.
However, the effort estimate can help in other ways to meet a deadline set by the market. Example: A project may only last one week, but the sum of the work packages results in a longer project duration. What could be done? Either reduce the scope or add more employees to the project. But be careful: twice as many people never add up to half the time. Firstly, the communication effort increases exponentially with the number of people in a group and secondly, many tasks cannot be parallelised at will.
How useful is it to compare T-shirt size plans with each other?
Jan Hegewald: I think it makes sense to compare the T-shirt size plans with each other. If you want to use the plans as a basis for prioritisation, all projects should have the same effort range – e.g. as described above “S” with 1-2 team weeks, “M” with 3-6 team weeks, etc. This makes it possible to choose the “cheaper” option for two undertakings with similar benefits but different levels of effort.
By the way: In my opinion, story points are not suitable as a basis for prioritisation across projects.
[1] The article “Why are software development task estimations regulary off by a factor of 2-3?” describes the discrepancy between effort estimation and effort very clearly.
Jan Hegewald blogs about modern leadership and agility at https://www.agil-gefuehrt.de. And at https://www.jan-hegewald.de fyou will find further content on topics relating to digital product development. You can easily get in touch with him on LinkedIn.
If you like the article or want to discuss it, feel free to share it with your network.
Jan Hegewald has published two more posts on the t2informatik Blog:
The agile migration of an application
Conway’s one way street
Jan Hegewald
Jan Hegewald is VP Engineering at SumUp Ltd. in Berlin. Previously, he was Director of Engineering for Product and Category Experience at Zalando SE and Head of Technology B2B at idealo internet GmbH.
Before that, he spent many years designing, building and implementing customised IT systems for critical core processes for large companies. He also advised a wide range of clients on project, programme and portfolio management methodologies, in each case with a view to processes, organisation, tools and the personal skills of employees.