There are three Quantified Task measures involved in estimating effort on a Task: Distance, Friction, and Relativity. Each is useful by itself, and you can combine them to get Energy Points, which are used like Agile story points.
What To Estimate On
Estimation Measures are meant to be used with User Stories, or else with single, actionable Tasks.
Do not use estimation measures on Epics. Instead, for these you should refer to the averages from all the Tasks. (See the Rule of Estimation.)
You may consider separately estimating on each distinct value-adding Phase of a Task, such as Implementation, Testing, and Code Review.
Distance
Distance is the estimated time it would take to complete the Task, assuming total proficiency and knowledge about every aspect. This assumption is crucial in controlling for different levels of experience, as we only want to measure the Task, not the skill of the Developers. It is also important not to let elements of uncertainty in the Task affect this estimate, as that is covered by the other two measures.
Despite the association with time, you are actually measuring implementation effort.
Distance is measured relative to your sprint duration. If you don't use an Agile methodology, you can still measure relative to a two-week period, the duration of a traditional sprint.
d1: Within day.
d2: Within quarter sprint.
d3: Within half sprint.
d4: Within sprint.
d5: Exceeds sprint. Typically indicates Task should be broken down into subtasks.
To help you visualize this, here are the distances relative to particular sprint durations.
| 1 week | 2 weeks | 3 weeks | 4 weeks |
d1 | < 1 day | < 1 day | <= 1 day | <= 1 day |
d2 | 1-2 days | 1-2½ days | 2-4 days | 2-5 days |
d3 | 2½-3 days | 3-5 days | 5-7½ days | 6-10 days |
d4 | 4-5 days | 6-10 days | 8-15 days | 11-20 days |
d5 | > 7 days | > 10 days | > 15 days | > 20 days |Again, if you don't use Sprints, use the 2 week schedule.
If your Solution has a high average Distance, this indicates high complexity. Look for opportunities to break down Tasks into subtasks.
Friction
Friction is a measure of available resources to help complete the Task. Importantly, this is not a direct measurement of difficulty, as that would be relative to the skill of the Developer.
Resources to consider include:
Reference materials like documentation, articles, tutorials, and lectures. Consider the recency of such materials.
Precedent, either internal or external reference. For software engineering precedent, the overall health of the reference code -- good practice, patterns, clean coding -- should be taken into account. Also consider the language, language version, and relevant dependency versions. If your Task is in Python, code in Rust is likely less relevant than code in JavaScript.
Direct availability of subject-matter experts to advise.
Also consider the health of the source code for the Task. Raise your Friction score if the code is objectively difficult to work in, relative to good practice in the language.
Remember to measure Friction objectively and empirically. It must never take a Developer's actual skill or experience as a factor.
f1: Highway. Low-skill Tasks, tutorial-guided work, low-hanging fruit, housekeeping.
f2: Street. Good reference materials, close precedent. Work occurs in relatively healthy source code. Some innovation may be required.
f3: Off-Road. Some reference materials, reasonable precedent. Significant innovation may be required, or work may occur in somewhat unhealthy source code.
f4: Trail. Sparse reference materials, distant precedent. Mostly innovation, or work occurs in particularly unhealthy source code.
f5: Jungle. Uncharted territory. This issue ticket will self-destruct in fifteen seconds. Good luck, Mr. Hunt.
If you're uncertain about the Friction of a Task you're estimating, it is usually possible to establish an initial estimate with a cursory web search. If you cannot, increase the Relativity or schedule a spike.
When selecting tasks to work on, a Developer can pair Friction with their own assessment of their experience in the code and technical stack to find work appropriate to their skill level.
A high average Friction on a Solution indicates that you need senior Developers or subject-matter experts on the team.
Relativity
Relativity is a measure of uncertainty, which we call "flux". It indicates the likelihood that the Task is a "black hole" -- its completion date is indefinite, and the more you work on it, the further you seem to be from completion.
This is part of what makes Quantified Tasks so useful. Instead of effectively lying about our estimates, as virtually all other project planning techniques do, we literally measure and report that uncertainty. The higher the Relativity score, the more likely the Task is going to take longer than projected.
A useful analogy is to think of your Solution as a route on a geographic map. Each uncertainty in your Solution is represented a "flux-bridge", or a bridge of indeterminate length. It could be inches, feet, or miles long! We don't know how long these flux-bridges are, but we can typically count how many lie along a route. This is what Relativity is about.
r1: Trivial Flux. Virtually no unknown factors.
r2: Low Flux. A few identifiable unknown factors.
r3: Moderate Flux. Several unknown factors, but completion is still feasible.
r4: Significant Flux. Extensive unknown factors. Completion infeasible without eliminating some flux.
r5: Total Flux. Black hole, completion believed impossible. Task must be abandoned or refactored.
Notice, there is always some flux in any Task. Nothing is certain but death, taxes, and bugs.
A high average Relativity across a Solution may indicate significant uncertainty in the design.
IMPORTANT: If you eliminate some flux from a Task while working on the Task (e.g. not from another work item with its own estimate), DO NOT lower the Relativity score. That original Relativity score is how the effort to eliminate the flux will be represented in the Velocity, regardless of how much time it actually took.
Energy Points
Energy Points are a composite unit of estimated effort required to complete a Task. This is calculated with the formula (Distance + Friction) * Relativity. This value is reliable as an estimation tool because it accounts for implementation (Distance) and research (Friction) effort separately, and then scales the estimate according to the degree of uncertainty in the Task (Relativity). The idea of multiplying by Relativity comes from the idea of multiplying software estimates by three to account for delays from unknown factors.
When recording Energy Points on a Task, you should ensure that you record Distance, Friction, and Relativity separately. If you do not have the option to store these in separate fields, you would store the Energy Point score in the "story point" field, and then write the full Energy Point equation in the Task description, like this:
(d2+f3)*r2 = 10(See also, Issue Tracker Usage.)
As you get used to working with Energy Points, you will come to understand how much work you can take on in a given sprint. This is useful for allocating work and determining if your team will need additional Developers. Since Distance is relative to a sprint, the average energy points you can complete in a sprint will often remain consistent even with sprints of different length. As a result, however, Energy Points are "heavier" in longer sprints; you'll be able to clear less points in a session when the sprints are longer.
Energy Points are used in place of Story Points or T-Shirt Sizes in Agile workflows. (See also, Story Points or Energy Points.)
How To Estimate
You can create an initial estimate for most Tasks in under a minute. Remember, this is only an estimate! You should update these measures later as you learn more about the Task.
If you estimate as a team, I recommend using the "planning poker" technique, but with each team member voting on each of the three measures at once, like this:
d3 f2 r3
In practice, it doesn't take longer to settle all three of these than it would one number. The same conversations take place -- effort, precedent, and uncertainty -- but these insights are captured in the numbers.