In traditional waterfall style project management, a project manager will work with project stakeholders to scope a project and estimate timelines for delivery at each stage or phase of the project.
If you work in a complicated environment like civil engineering, that’s ok because civil engineers and project managers have built heaps of bridges and they have a great understanding of how long that will take and what will be necessary to complete the bridge on time.
In complex environments where the problem you are attempting to solve has never been solved before or the product that you are looking to build has never been built before, things become a great deal more complex.
A product owner and development team will instead look to estimate the size of the items that need doing and attempt to estimate how difficult or how much effort is required to deliver that item.
Pigs on a road
Whenever I’m asked this question, my mind casts back to a conference I attended where the speaker spoke of the challenges presented by pigs on a road.
On a normal, clear day it might take 2 hours to travel from one village to another. On any given day, you may also encounter a farmer with pigs on the road that could set you back a few hours as you wait for the pigs to reach their destination before you can proceed.
So, without any challenges or complex variables, it’s safe to estimate that you would need 2 hours to reach your destination but that could vary by as much as 3 extra hours depending on unanticipated or unexpected variables.
That’s the challenge with estimating time. You don’t know what is going to get in your way and you don’t know what kind of challenges are going to prevent you from delivering on time.
Into the unknown
Anything we are doing in the product development space has not been done before.
The problem you are attempting to solve or the product that you are seeking to build has never been solved or built before.
There is an unknown number of variables that could impact the size of the problem or the complexity of the build and as such, anything could disrupt the process at any given time.
Ideally, we only build things once so nothing about your work is a repeatable element that has a clear path from A to Z. You are certainly going to be building from a solid platform, but this is the first time you will work with X team, in X context, given X technologies and the size of the problem.
In complex environments, it just doesn’t make sense to estimate in time.
Estimating Work
A useful metaphor is that of effort.
In a gym environment, one of the most popular strength movements is the squat.
You place a load on your shoulders and squat that weight up and down over a series of reps.
A 100kg squat requires X amount of effort.
You may have done that squat countless times and you may find that it’s relatively straightforward or you might have encountered it for the first time, and you may find it difficult and challenging.
Either way, physics dictates that the amount of effort required to move 100Kgs is 100Kgs of effort.
Estimating the effort required or size of the problem is a much better way of estimating work than attempting to estimate how long it will take.
Estimate in effort and your estimates will remain consistent.
Even if something gets easier over time, the effort remains the same, you simply have a greater capacity for work than you did before.
Estimation of effort empowers the team to make educated and relatively accurate estimates of how much work can be delivered within a relative time frame such as a sprint.
Product Delivery
A team may average 40 points worth of work delivered in a 2-week sprint.
As they get better, they might improve that to 50 points of work within a given period and use tools like sprint burndown charts to measure how much work is consistently delivered in a given period and estimate future productivity based on past performance.
If you are measuring in hours, say 400 hours’ worth of work in a given sprint period, and you get better at doing that work then you have to re-estimate everything.
Since you are now attempting to measure in hours rather than effort, you must reevaluate how many hours it takes to complete a given task and then multiply that guess by the number of tasks you are going to attempt in a given period.
If there are changes in the team or challenges that present themselves, your estimation of time will be thrown out based on the new variables and you will find that your estimates are inaccurate.
A measure of work in the form of effort and points doesn’t pose that same problem.
The amount of effort required remains the same regardless of the variables.
This is why scrum teams use sprint burnup charts and sprint burndown charts to measure their progress against time.
Doing so empowers them to make more accurate estimates of work to be completed in a sprint based on past performance and forecast how much work will be delivered within the upcoming sprint.
If you like the idea of becoming a scrum master, visit our Certified Scrum Master course page.
If you are already a scrum master and want to upskill, visit our Advanced Certified Scrum Master course page.
If you have several years’ experience as a scrum master, visit our Certified Scrum Professional Scrum Master course page.
If you like the idea of mentored and coach-driven skills development, visit our Agile Coach Academy.
If you have identified coaching as a valuable skill to develop, visit our on-demand Introduction to Coaching course page.
For more information on John McFadyen, visit https://www.growingscrummasters.com