Quantified Task Management [QTM]

Version: 1.2.1

Last Updated: 2019-10-30


For decades, programmers and managers have struggled to create a reliable system of tracking tasks and bugs. Managers need quantified (countable) ways to determine how much work has been done, and how long it will take until a task or project is completed. Programmers need to be able to manage their time, determine the importance of bugs and tasks, and predict release dates.

As depicted in Dreaming in Code by Scott Rosenberg, among many other books, quantifying programming is extremely difficult. Some companies have tried tracking lines of code written, but how should optimization (which actually removes lines in the process of making the code more efficient) be tracked? Others try to watch how many bugs were fixed or how many features are completed. However, not all bugs and features are equal in size, importance, or priority.

Three elusive main goals are needed for efficient project management:

  • Quantification: It needs to be based in numbers.

  • Granularity/Standardization: Everything must be measurable by the same system in order to make accurate comparisons. (We can’t accurately compare equal sized crates, one filled with feathers, and the other with bowling balls.)

  • Specificness: Over-generalization makes for less accuracy. The system should be able to track important task/bug metrics separately, not mush them all into one cover-all term.



Priority refers to how soon this task needs to be accomplished. A task can be a low priority temporarily, and yet still have a high Gravity.

  • p5: Immediate. Reserved for escalating a task above all other priorities; “drop everything and do this!”

  • p4: Important. The usual top priority, and whatever is currently being worked on.

  • p3: Normal. Tasks that should be completed in the current development cycle, after current p4 and p5 tasks.

  • p2: Soonish. Tasks that don’t necessarily need to be completed in the current development cycle.

  • p1: Eventual. Tasks which are not slated to be completed in this current development cycle.

  • p0: Wishlist. Tasks that don’t necessarily need to be completed.

  • pT: Triage. Tasks which are not yet prioritized.

Gravity (Importance)

A task’s Gravity is its importance to ensuring the project is stable, easy-to-use, and accomplishes all of its intended goals. It plays an important role in planning. This is the only measure over which a client should have direct control.

This measure is especially useful when performing a “featurectomy” (removing features from a project to expidite it’s completion.)

  • g5: Critical. Project can’t exist without. Must be completed, period. Should never include aesthetic and convenience functionality.

  • g4: Significant. Must be completed, only cut if desperate. Includes only functional requirements which directly improve on g5 features. (No bells-and-whistles.)

  • g3: Major. Non-essential, but should be completed if time permits. “Polishing” tasks, and the most important bells-and-whistles.

  • g2: Minor. Not slated for current release, but may be g4 or g5 for next release.

  • g1: Trivial. “Would be nice” tasks; these take backseat to the completion of all other tasks. Should contain only tasks that could reasonably belong in the project at some point; this is the pool for selecting g3 tasks for future releases.

  • g0: Wishlist. All other tasks which have been properly discussed, but no higher Gravity rating could be determined.

  • gΣ: Sum of all subtasks. Use this for umbrella tasks that don’t have a Gravity of their own. The Gravity will be the sum of the Gravity scores of its subtasks.

  • gT: Triage. Proposed and unconfirmed tasks.


Gravity is discussed in detail in an article by Lead Developer Jason C. McDonald entitled Three Ground Rules for Sane Project Planning

Friction (Available Help)

Friction is a quantified measure of difficulty, based on how many resources are available to help complete a task. This does not involve the person’s actual experience, as that varies from person to person.

The following table shows how this could work, rating each aid as Full, Some (similar to goal), Little (dissimilar to goal), or None.


























Back Road























Relativity/Black Hole Probability (Uncertainty)

It can be easy to predict how much effort and time will go into a task, or it can be very hard. We can call this uncertainty “flux”. Relativity is essentially a measure of how much flux is present in a task, and conversely, how reliable our time and effort predictions are.

A task becomes a black hole when you have absolutely no idea how much time or effort the task will require.

A good rule of thumb: you will know the relativity within the first hour of working on a task.

  • rT: Triage. Relativity not yet determined for task.

  • r0: No chance of black hole. No flux.

  • r1: Low black hole probability. Probably safe.

  • r2: Moderate black hole probability. Some flux, but looks possible to complete.

  • r3: High black hole probability. Still possible to complete, but take caution.

  • r4: Almost-definite black hole. Completion possible, but unlikely.

  • r5: Collapsing. Bail out NOW. Task needs to be abandoned or re-factored - it is virtually impossible in its current state.


Relativity and flux are discussed in detail in an article by Lead Developer Jason C. McDonald entitled Gallifreyan Software Project Management


Cumulatively, Volatility measures how late in the development process bugs are being caught. This can be used to spot issues in software quality processes, and to provide an estimation of software stability.

Volatility has two parts, although only one is absolutely necessary. The first is the Volatility measure on the bug itself, indicating what development stage it was caught in.

  • vN: Not a bug. Feature requests and other non-bug issues should always have this rating (or else v0 if you can’t implement vN.)

  • v0: Caught in Design phase. This means the bug was anticipated before coding even began.

  • v1: Caught in Coding phase. This means the bug was caught before it reached a protected branch, such as devel .

  • v2: Caught in SQA (Testing) phase. This means the bug landed a protected branch, such as fresh , but was caught before reaching production.

  • v3: Caught in Production phase. This means the bug actually shipped to end-users (i.e. it reached stable).

The second part of Volatility is optional, but may be useful to certain teams. Origin indicates which development stage the bug originated at.

  • oN: Not a bug/Unknown This should be used for non-bug issues, and also if the origin cannot be determined.

  • o0: Originated in Design phase. This usually means the bug is a logic error or impossible expectation that formed during the pre-coding Design process.

  • o1: Originated in Coding phase. Almost all bugs are created during the actual code-writing process.

  • o2: Originated in SQA (Testing) phase. For example, if a bugfix made at this stage causes another bug to form, this would be the origin.

  • o3: Originated in Production phase. This usually means the bug was created during the process of preparing devel for shipment.

You can combine these two metrics to get the Adjusted Volatility [AV] score for any bug:

AV = v-o

The Adjusted Volatility allows you to account for how much opportunity developers had to catch the bug. For example, a mistake made during packaging is worth noting, but it isn’t nearly as alarming as a bug introduced in the design phase, but not caught until after it shipped to users.

Volatility’s true strength is in project management. See Project Volatility Scoring to learn how to calculate and use this metric.


Volatility is based on the article How I Measured The Software Testing Quality and the subsequent comment chain.


To get the best sense of what has been done by a developer in a given time period, we’d look at the average Gravity, Priority, and Friction.

Here is a table of examples of the system in action.

Legend: measureTOTAL(AVERAGE))


Total G

Total P

Total F






Important (but probably easy) overall accomplishments, though few of them needed to be done now. A good week’s work.





The tasks were urgent right now, but not important in the big scheme of things. Probably easy. A good week’s work.





Moderately important tasks, all extremely difficult. A HUGE accomplishment.





A lot of tasks were done, but none were very urgent or important, and all were really easy. Not as impressive as the task count seems.

These numbers have to be taken in context with other factors, of course, but they give a MUCH more accurate picture than other management and tracking methods.

Project Volatility Scoring

The Volatility metric is most useful in catching problems within an overall project or team.

To calculate a project’s Adjusted Volatility score, use the following equation:

A = project Adjusted Volaility score
M = project's Mean Volatility score
b = number of bugs
v = sum of all bug volatility scores
o = sum of all bug origin scores

A = (bv - bo)/b
M = v/b

You may want to record both the project’s Mean Volatility (M) and Adjusted Volatility (A), as useful information can be garnered from both.

For example…

  • A very high A indicates that many bugs are slipping past review processes.

  • A high M and low A indicates that a lot of bugs are actually originating in SQL or Production phases.

Sometimes, tracking Origin just isn’t useful for your team, in which case you can just use M.