Estimation in agile development

4 min readDec 5, 2020

A dead horse doesn’t mind a few more punches

Content:

What is estimation?
Should I estimate and what unit should I choose ?

What is estimation?

“When will it be finished?”
“How much work can we put into our sprint plan? What is our load vs capacity? Are we overcommitting?”

The above are common questions which every development team faces. Estimation is a practice of assessing size of a development work item (a Story or task). Purpose of estimation is using the assessments to come up with reasonable amount of work could be completed in a timeframe, like a two-week sprint.

For example, based on historical data, given their estimation reference hasn’t changed, a team knows they can complete about 150 story points worth of work. This is sometimes referred to as the team’s “velocity”. That means if the team is running at unchanged composition, they shouldn’t plan for more than this amount of work into their next sprint, if they are to maintain a sustainable pace.

Another use for estimation — a valuable one — is to facilitate shared understanding of a work item within a team. Since it’s being built as a team, has everyone understood it the same? In this setting, the estimate itself isn’t valuable, it’s the act of estimating which might trigger conversation and highlight differences in understanding of a work item amongst team members.

Should I estimate and which unit should I choose?

Units of estimation, or using estimation at all, is a choice of the development team — whichever works best. Remember that if you work as cross-functional team, you estimate as a team. Not as an individual on behalf of others.

Teams using Scrum commonly do estimate as part of sprint planning.

Teams using Kanban can use estimation to facilitate shared understanding of a work item within a team and ensure work items are roughly the same size.

Personally, based on my experiences I am partial to not recommending estimation for purposes of prediction as the value add compared to the efforts isn’t there, but this depends on your context and the organization you operate in.

If you still are going to estimate, these are the typical choices of unit:

Story points (How big is this item in story points?)
Time (How many days might this item take to complete?)
Number of stories or tasks

Story points

Established assumably by Ron Jeffries, use of story points, typically a number from the modified Fibonacci series (1–2–3–5–8–13–20–100-?-coffee break..) is used to compare work items relative size to each other.

The logic behind comparison is that if one was looking at a skyscraper, it would be difficult to estimate its height in meters accurately. However, when looking at two skyscrapers side by side, it’s easy to tell which is higher than the other.

Modified Fibonacci series is used instead of a linear scale like 1–10, to counter the inherent inaccuracy and uncertainty when estimating something that’s never been done before. First a reference point (the first skyscraper) needs to be set, which the entire team understands. Then a comparison is made. For example: “This item is a “5” and this other one is much larger, so we estimate it as “13”.”

Story points are often agreed on and assigned in an activity called “planning poker” which is well covered in numerous articles on the internet.

Pros

well established practice with lots of articles and free tools available
practical for comparing sizes of items in relation to each other with no absolute unit
can be a fun way to facilitate shared understanding

Cons

Story points are a like ordinal numbers (indicating position, like 1st, 2nd, 3rd etc..) which cannot be meaningfully be added up, divided, multiplied or otherwise crunched in terms of arithmetics, like cardinal numbers can. This is often not understood, even though many frameworks suggest indicating velocity, added up, as points.
Often mistakenly just converted to a linear timescale, “1 point — about one day, 3 points- about three days”. No.
Hard to normalize across teams or different sprints if the reference point changes. “1 story point isn’t the same size in team A as it is in team B.”

Time

Simply use time as the measure of estimation. “We estimate as a team that this work item will take three days to complete.”

Pros

time as a unit of measure is easy to understand by everyone
easy to track actual vs estimated time, as they are in same unit
easily converted to cost in currency, if necessary

Cons

inherently and misleadingly inaccurate, especially when bigger items are estimated down to a level of hours or minutes
can take tremendous mental effort and cause frustration due to perceived expected accuracy vs known reality of inaccuracy in estimation
easy fallback to calculating in“man-days” which does not work in software development, if you work as a cross-functional team. “Two women cannot complete pregnancy in 4,5 months.”

Number of stories or tasks

The number of work items completed over a timeframe, also known as issue count. “How many items can we complete over time x.” Statistically proven to be as accurate as the other methods to project completion time. Especially if the backlog is properly groomed to be of relatively similar size items.

Pros

little to no upfront estimation effort required — massive time and effort saver
statistically proven to be equally accurate as other methods in projecting completion time
requires no time tracking, number of completed items can be used to project a completion time