Overview

Your Tasks, Measured.

How do you measure a task? The question has plagued project managers, software engineers, and product owners alike for decades. Do we measure in urgency? Estimated time? Work produced? Or can tasks only be measured relative to one another? None of these answers ever quite represent all the complexity a single task contains.

This is where Quantified Tasks comes in. By considering six attributes of any task – attributes you probably already think about – and placing them on five point scales, you unlock significant, practical insight into your tasks, your sprints, and the project as a whole. Best of all, this insight is easily shared and understood by all stakeholders in the project: stakeholders, product owners, managers, and developers of all experience levels. Quantified Tasks informs project goals, schedules, sprint planning, and allocation of work.

Quantified Tasks is to estimation and planning what Agile is to project management.

Measures at a Glance

Quantified Tasks has six core measures: Impact, Gravity, Priority, Distance, Friction, and Relativity.

You can optionally monitor the Stability of your solution with Quantified Tasks too. To accomplish this, there are two additional measures for issue reports: Origin and Caught.

All measures in Quantified Tasks use a scale of 1 to 5.

The Planning Measures

In planning, Quantified Tasks distinguishes between the importance of a Task, which is typically fixed, and the urgency of the Task, which is fluid.

Impact is the importance of a Task to the goals of the Solution. i5 is considered absolutely essential, while i1 is a wishlist item. Impact is defined primarily by the Product Owner, in collaboration with the Stakeholders.

Gravity is the importance of a Task to the next Release. g5 is a must-have, while g1 is not slated for inclusion. Gravity is defined by the Product Owner in collaboration with both the Stakeholders and the Developers.

Priority is the urgency of the Task, particularly in relation to the current Sprint, somewhat akin to a Kanban perspective (Now/Next/Later). p4 is considered a “Now” task, while p1 is explicitly omitted from the schedule. p5 is a special value, indicating an “Emergency” task. Priority is defined by the Developers and Product Owner as part of sprint planning.

The Estimation Measures

Quantified Tasks empowers effective and honest (yes, really!) effort estimation, making it useful for roadmaps, sprint planning, and more.

Distance is the estimated time frame for completion relative to a Sprint, if you understood everything about the Task. d1 would be a single work session, while d5 would exceed a sprint.

Friction is a measure of available documentation and precedent for completing the Task. f1 would be a Task for which there is a complete tutorial, while f5 would be pure invention.

Relativity is a measure of uncertainty, or the likelihood that the task is a “black hole” with an indeterminable completion date. r1 would be a task with no known uncertainty, while r5 has virtually no certainty.

The formula (Distance + Friction) * Relativity yields an Energy Points value. This can be used in the same manner as Story Points or T-shirt sizes. Possible Energy Point values follow a non-linear curve. Scores are higher when confidence is lower (Relativity is higher), ensuring estimates leave room for unknowns.

The Stability Measures

Issues have two more measures in Quantified Tasks. These measures reveal patterns about the stability of your Solution. The numbers map to the main phases of the Software Development Life Cycle.

Origin represents the stage at which an Issue originated: Planning (O1), Design (o2), Implementation (o3), Validation (o4), or Production (o5).

Caught represents the stage at which an Issue is detected, from c1 to c5, following the same stages as Origin.

The Volatility is calculated as (Caught - Origin) * Impact. The longer the Issue evaded detection and the greater the Impact on users, the higher the Volatility.

Taking the average (mean) Volatility gives you a Solution Volatility. This is a predictor of the stability of your Solution as a whole, because typically more Issues exist than are caught and reported.

Rules and Glossary

When implementing Quantified Tasks on a team, there are a few rules you should abide by. These ensure the methodology is consistent and reliable enough to use for decision-making.

We’ve also defined the terms used throughout Quantified Tasks.

FAQ

Is the Quantified Tasks technique compatible with Agile, Scrum, and/or Kanban?

Yes! Quantified Tasks is simple enough to fit in with your existing workflows, especially Agile. In Scrum, you would use Energy Points in place of Story Points. In Kanban, you’d associate Priority with your board columns.

Is Quantified Tasks compatible with my issue tracker?

There are a few ways to use Quantified Tasks in your issue tracker, depending on its features.

What about story points, T-shirt sizes, or Fibonacci numbers?

Can Quantified Tasks help me understand developer accomplishment?

Who developed Quantified Tasks?

Quantified Tasks was conceived and developed by Jason C. McDonald, a Software Engineering Manager and Principal Software Engineer with over a decade of experience leading teams and projects.

The concept of Volatility was originally devised by Kashif Gul Kazi, in his article How I Measured The Software Testing Quality. It was adapted and expanded by by Jason C. McDonald.

How is this related to Quantified Task Management?

The Quantified Task Management standard, originally published by MousePaw Media, is the predecessor of Quantified Tasks. The name was simplified in this new version, partly to avoid confusion with another QTM (Quantitative Trust Management), and partly to move away from the bureaucratic sound of the word “management”. A few improvements to the standard were made besides.

A revised version of the Quantified Tasks standard was published to GitLab in late 2022.