Search
Close this search box.
Search
Close this search box.
Search
Close this search box.

The horrible truth about software development estimation, and what to do about it

Facebook
Twitter
LinkedIn
Pinterest
WhatsApp

In recent years I’ve been working with many software development teams and almost all of them struggle with estimating the work. The energy spent on this and the frustration it causes should come to a halt. And so, in this short article, I combine knowledge gained by many people with my experience and explain how to address this.

A significant amount of time is spent on estimating the work required to build software. I’ve seen teams spending around two days every two weeks trying to understand how much the work will cost, with organizations spending valuable time of managers and experts haggling, pushing and fighting over estimations.

Does it work? Do they get the estimations right? No, they don’t. Why? Simply put, building software is complex. We think we know what’s ahead of us, but we just don’t. This is very difficult to grasp and accept. Requirements evolve. Design evolves. We gain understanding through the work. Things change all the time.

And so, as your expertise increases you come to the conclusion that, while it is usually possible to know the magnitude of order (hours/days/weeks), accurate estimation of the work in hours, days, weeks or months is almost impossible.

This is a great breakthrough, as once you understand this reality, that accurate estimation of software development is not possible, you can start moving forward.

What can be done? How can we have a prediction of when things will get done?

Reduce possibility of development going out of control

The key to the solution is to reduce the possibility of the development process getting out of control. Instead of trying to figure out how much effort it will take to develop features, we take two main measures to increase the predictability of our development process.

The first measure is keeping the batch size, the amount of requirements we develop, small enough. This is because the complexity of development increases at an exponential rate with the growth of the number of requirements.

The main question, therefore, when estimating work is not how much effort it is but rather is it in the right size. If it is too big we need to break it down to smaller pieces.

The right size may change from team to team according to several factors, but from my experience a software development team working with modern tools usually aims towards a few days per development item, something that can be demonstrated to a product manager.

Below see a cycle time control chart of a development team, produced from Jira Software. Each dot is one or more development items that ended on the time indicated by the X axis. The Y axis shows how long it took to develop that item. This team’s average cycle time is around 4 days, but from time to time There are items escaping that average – the team discusses these items in order to improve.

As written above, the first thing to do to handle the problem of estimating work items is to try and bring them down to a size the team is comfortable with. Whether it is 2, 3, or 4 days doesn’t matter – what matters is that it is more or less the team’s usual size, which gives plenty of space for changes during the actual development.

Increase development predictability

The second approach to adopt to increase development predictability is combining forces, working together as a team.

To handle the complexity of software development we use a whole team approach. The team plans its work and does it together. The approach of the team leader making the plan and then each team member getting an assignment that they work on alone doesn’t work.

Practically, what does “Teamwork” mean? It means planning together: the team looks at the scope of items, determines together whether they are small enough (see above), and decides on their forecast for the development period. The team then starts handling the various items. They take items according to priority and work on them together. Working on items together sometimes means working on two parallel streams of the same job, sometimes it means sitting together at one development machine (pairing). It means that according to need and priority people switch tasks to help their teammates, and in general, the team does whatever it takes to get the work done.

Here is an example of a team who moved from investing a lot of time (2 days per person per 2 weeks) on estimating to working together and avoiding exact estimation. The gray columns are how much was planned for a development period and the green columns are how much was actually done (the changes in throughput are due to personnel changes)

To summarize, instead of being heartbroken over spending endless time on estimation and not hitting the estimates, strive to break your work into smaller, lower complexity items and focus on teamwork. Software development work is thinking. And nothing beats thinking together.

(Photos by ThisisEngineering RAEng on Unsplash)

Subscribe for Email Updates:

Categories:

Tags:

ScrumMaster Tales
speed at scale
Covid19
Tools
Certification
Lean Agile Leadership
What Is Kanban
Atlassian
Managing Projects
Atlaassian
EOS®
Nexus vs SAFe
Large Scale Scrum
ATDD vs. BDD
Effective Agile Retrospectives
Professional Scrum with Kanban
Elastic Leadership
System Team
Kanban Kickstart Example
LAB
Operational Value Stream
An Appreciative Retrospective
Introduction to ATDD
Agile
Manage Budget Creation
POPM
Agile Project
Kanban Basics
Team Flow
SPC
Agile Development
Agile Release Planning
Kaizen
Portfolio for Jira
Spotify
Tips
Nexus
Presentation
Managing Risk on Agile Projects
Agile Program
Scrum Guide
Hybrid Work
Artificial Intelligence
Agile Games and Exercises
Value Streams
Principles of Lean-Agile Leadership
Kanban Game
Agile Risk Management
Continuous Integration
Lean and Agile Principles and Practices
Agile and DevOps Journey
Release Train Engineer
Process Improvement
Legacy Code
Coaching Agile Teams
Slides
agileisrael
Agile Outsourcing
SAFe
Lean Risk Management
Scaled Agile Framework
speed @ scale
Scrum Master
AI Artificial Intelligence
Story Slicing
User stories
Professional Scrum Master
Agile Marketing
Jira Cloud
Agile Testing Practices
Agile India
Applying Agile Methodology
Built-In Quality
Frameworks
Entrepreneurial Operating System®
Self-organization
Implementing SAFe
A Kanban System for Software Engineering
Professional Scrum Product Owner
Continuous Deployment
Agile Techniques
Introduction to Test Driven Development
Iterative Incremental Development
Jira Plans
Risk-aware Product Development
Sprint Retrospectives
Agile Games
Planning
Sprint Iteration
Continuous Planning
Program Increment
Amdocs
Agile Project Management
Webinar
Continuous Improvement
Lean-Agile Software Development
Legacy Enterprise
Agile Community
Kaizen Workshop
Nexus and SAFe
Nexus Integration Team
Agile Contracts Best Practices
Lean Agile
Agile for Embedded Systems
Risk Management in Kanban
Lean Agile Organization
Lean-Agile Budgeting
Perfection Game
Risk Management on Agile Projects
Change Management
The Agile Coach
NIT
Agile Product Ownership
Scrum Master Role
Test Driven Development
Continuous Delivery
Agile Product Development
ART Success
predictability
Lean and Agile Techniques
Code
Agile in the Enterprise
RTE
Accelerate Value Delivery At Scale
Enterprise DevOps
Agility
Agile Release Management
RTE Role
Kanban 101
Agile Israel Events
DevOps
GanttBan
Agile Israel
Agile Delivery
Releases Using Lean
ARTs
SAFe DevOps
Jira admin
Implementation of Lean and Agile
chatgpt
Software Development Estimation
PI Objectives
Jira
Lean Agile Management
Lean Budgeting
Quality Assurance
Agile Assembly Architecture
PI Planning
System Integration Environments
Agile Exercises
Rapid RTC
Agile Basics
Engineering Practices
Video
IT Operations
Sprint Planning
lean agile change management
System Archetypes
Scrum
AgileSparks
Development Value Streams
Lean Software Development
Advanced Roadmaps
Agile Mindset
AI
Business Agility
Certified SAFe
SAFe Release Planning
Limiting Work in Progress
WIP
Achieve Business Agility
SA
LPM
Nexus and Kanban
Keith Sawyer
Scrum Primer
TDD
BDD
Scrum Values
The Kanban Method
Lean Agile Basics
Scrum.org
Scrum With Kanban
Reading List
ATDD
LeSS
Pomodoro Technique
ROI
Systems Thinking
Kanban
Scrum and XP
ALM Tools
QA
RSA
Software Development
Product Ownership
Product Management
Lean Startup
Games and Exercises
Acceptance Test-Driven Development
AgileSparks
Logo
Enable registration in settings - general

Contact Us

Request for additional information and prices

AgileSparks Newsletter

Subscribe to our newsletter, and stay updated on the latest Agile news and events

This website uses Cookies to provide a better experience
Shopping cart