Here are a few ground rules for implementing Quantified Tasks, to help you get the most out of it.
Rule of Planning
Every Task with a Priority must have a Gravity, and every Task with a Gravity must have an Impact. Impact analysis is critical for every Task and Epic.
Rule of Pareto
High Impact (i5 and i4) and high Gravity (g5 and g4) Tasks should account for only approximately 20% of the backlog respectively. If everything is important, nothing is important.
Rule of Estimation
Every Task with a Priority must also have Distance, Friction, and Relativity. If you aren’t going to work on the Task, you can wait on estimating. Epics do not have estimates of their own.
Rule of Phases
Every Phase of a Task, as outlined by the project’s Definition of Done, should contribute to the estimation. In many cases, it will be worth separately scoring each such Phase. This ensures that all work contributes to the Velocity. Each Phase inherits the Impact and Gravity of its Task.
Rule of Subtasks
When scoring a subtask, rescore the parent to exclude factors from that subtask. This ensures you do not count various factors twice.
Typically, Epics are not estimated (see Rule of Estimation), although you may choose to calculate the sum and average of their Distance, Friction, and Relativity.
Rule of Fives
A “5” on any metric should be considered a warning:
i5: The task is essential to the solution.
g5: The task must be done in this release.
p5: The task is an emergency, and must be done now.
d5: The task should be broken down into subtasks.
f5: The task requires a Spike.
r5: The task must be refactored to eliminate some unknowns.
o5: Quality control gates have been bypassed. (This is serious!)
d5: Quality control gates have failed.
Rule of Emergencies
A Priority of p5 indicates an emergency. A justification for the emergency rating, a timeframe, and a description of the project consequences if the emergency is unaddressed should be included.
Rule of Ones
A “1” on any Planning or Estimation metric indicates that the task was actually assessed. If the value has not been determined, it should be left blank or (if a value is required), set to “Triage”.
i1: Stakeholders have approved this for inclusion.
g1: We plan to include it in a release eventually.
p1: We plan to work on it eventually.
d1: The task requires a small amount of work.
f1: A large body of reference materials exist to assist.
r1: We have identified virtually no unknowns in the task.
Rule of Issues
Every Issue which will not be resolved within 15 minutes of detection must have a Task in the issue tracker. Such a ticket must have an Impact, Origin, and Caught score. To encourage this, Origin and Caught should not have “Triage” options; Origin should default to o1, and Caught should default to c5, so the Velocity defaults to a high value.
Rule of Averages
The average of each metric on a task reveals helpful project management insight:
High Impact: Probable feature creep, or lack of proper Impact Analysis.
High Gravity: Release is overambitious, or tickets for future work aren’t being created.
High Priority: Sprints are overambitious, or tickets for future work aren’t being created.
High Distance: There’s a lot of actual work. If the team is falling behind, they may need more help.
High Friction: There’s a lot of senior-level work. If the team is falling behind, they may need more senior developers or subject-matter experts.
High Relativity: There are a lot of unknowns. The Solution may need to be refactored or redesigned to be completed.
High Origin: Quality control gates are routinely bypassed, or there is a lack of quality control gates prior to the Validation phase of the SDLC.
High Caught: Quality control gates are consistently failing, or the Rule of Issues is consistently being violated.
High Solution Volatility: The Solution is unstable. (Solution Volatility is the average Volatility.)
Glossary
Caught — one of the Stability measures; see Stability: Caught.
Developer — an individual responsible for Implementation. (Not limited to software developers.)
Distance — one of the Estimation measures; see Estimation: Distance.
Energy Points — the metric representing the estimated Developer energy needed to complete the Task. Largely analogous to Story Points. See Estimation: Energy Points.
Epic — a collection of work items in the issue tracker.
Friction — one of the Estimation measures; see Estimation: Friction.
Gravity — one of the Planning measures; see Planning: Gravity.
Impact — one of the Planning measures, also used in Stability; see Planning: Impact and Stability: Impact and Stability.
Impact Analysis — see Planning: Impact, Impact Analysis.
Issue — a Task representing any behavior which is unexpected to the end user, commonly referred to as a “bug” or “defect”.
Origin — one of the Stability measures; see Stability: Origin.
Personal Velocity — the total Energy Points completed by a single Developer in a Sprint.
Phase — a distinct step that moves a Task towards the Definition of Done, such as Implementation, Code Review, or Testing.
Priority — one of the Planning measures; see Planning: Priority.
Product Owner — the individual responsible for ensuring decisions are made and communicated about Solution goals.
Relativity — one of the Estimation measures; see Estimation: Relativity.
Release — a specific version of a Solution, planned with Gravity.
Stakeholder — an individual affected by the Solution or a problem that the Solution addresses.
Solution — a single project or product, planned with Impact.
Solution Volatility — the metric representing the average (mean) Volatility of all Issues on a Solution; see Stability: Solution Volatility.
SV — see Solution Volatility.
Sprint — a timeboxed development cycle, planned with Priority.
Task — a single work item in the issue tracker.
Team Velocity — the total Energy Points completed by the entire team in a Sprint. Usually what is intended by Velocity.
user group — a group of intended users of the Solution. The user group and their needs should be well understood and documented by the Product Owner.
Velocity — the total Energy Points completed for the Sprint. Usually refers to Team Velocity. See also, Personal Velocity.
Volatility — the metric representing the lifespan and severity of an Issue; see Stability: Volatility.