Hello, readers! I am working on plans for an official book about Quantified Tasks. As part of this, I’d like to be able to draw from the real world experiences of individuals and teams using this methodology.

If you use any part of Quantified Tasks, please reach out! What works? What doesn’t? What has helped your team? As a bonus, your insights and experiences may end up in the book. (I can anonymize and change the details if you prefer.)

Please email me at codemouse92 (at) outlook (dot) com and share your stories. Thank you in advance!

-Jason C. McDonald

Very hard, it turns out. Computers are insidiously literal beasts, and are terrible at many things humans take for granted, like inference and understanding visual data. Trendy technologies like AI and image recognition can only simulate those abilities, through a truly terrifying amount of applied mathematics.

Yet many stakeholders want to know when they can expect for the software to be ready, and how much it will cost to build it. Perhaps this is because, from the outside, software development doesn’t look that different from building bridges. Just find the right pieces, bolt them together, and everything should work, right?

Unfortunately, there are three things that are never predictable in software development:

• Problem complexity,

• Delivery timelines, and

• The viability of third-party code.

I have seen it time and again as a principal software engineer. The things that look like they should be easy are often the hardest of all. Up to this point, there have been exactly two ways of dealing with this in software estimation: (1) don’t commit to estimates, or (2) make your best guess, multiply by three, and pray nothing goes wrong.

Quantified Tasks creates a third option: plan with uncertainty! Imagine if, instead of coming up with a roadmap and stamping it with “here be dragons,” you could identify where those dragons might be hiding, and actually factor in the time to fight them?

Planning an Unlikely Journey

To understand how uncertainty works in planning, let’s consider a fictional journey. You are a powerful wizard tasked with guiding twelve dwarves and a hobbit from Hobbiton to Erebor.

Distance: As The Crow Flies

The first information you need is a roadmap. Consulting your atlas of Middle Earth, you find that the journey is approximately 1000 miles along the shortest route. If there are no delays or obstacles, the trip will take approximately 4 months.

In Quantified Tasks, this relates to Distance — approximately how long a task will take if the developer knows everything. Early in the planning process, you’ll usually have a list of Stories that need to make it into the next Release (Gravity scores of 4 and 5.) Your developers will be able to determine Distance scores for each of these Stories, and the sum total of the Distance for each will give you a good picture of how long the whole Release will take to complete if everyone knew everything.

However, as with unexpected journeys across Middle Earth, nothing ever goes quite according to plan.

Friction: Rough Road Ahead

It’s a simple principle: you can move faster along flat, well-worn road than you can over steep, rocky terrain. The higher the friction, the longer it will take to make the journey. In the case of our dwarves, they have good road for the first half of the trip, but then they’re going to have to cross the Misty Mountains. Later, there’s that whole leg of the journey through Mirkwood, which will be slow due to the darkness.

In our favor, however, we can find help at Rivendell, at the house of Beorn, and at Lake-Town of Esgaroth.

In Quantified Tasks, this relates to Friction — how many known obstacles exist to completing the task. Poor documentation, technical debt, unclear requirements, and even lack of precedent can increase Friction. Good documentation, available subject-matter experts, healthy code, and good precedent to study can all decrease Friction.

Still, the trouble areas we consider here are known obstacles. We can adjust our estimates with reasonable accuracy for increased Friction.

Now what about what we don’t know? This is where things get interesting.

Relativity: Unknown Factors

Anything we don’t know contributes to Relativity, which is the Quantified Task measure for the amount of uncertainty in a task. It is best thought of as a ratio of known factors to unknown:

• r1: Virtually no unknowns.

• r2: More known than unknown.

• r3: We know about as much as we don’t.

• r4: More unknown than known.

• r5: Virtually no knowns.

Even so, assessing Relativity may seem tricky: how can we measure what we don’t know? Let’s consider our map of Middle Earth. There are several places where we have varying levels of uncertainty:

• The Trollshaws have trolls. We know how they act, but we don’t know where they are. (r2)

• Both the north and south passes through the Misty Mountains have goblins, but we don’t know where they are or what they do. (r3)

• The Gladden Fields have been reporting a lot of Warg activity. We don’t know where they are or what they do. (r3)

• The north end of Mirkwood is against the Gray Mountains, which is heavily occupied by orcs, hobgoblins, and goblins. We have no idea what safe routes are there, if any. (r4)

• The Elf-path through Mirkwood is dark, narrow, and intersecting the Enchanted River that puts people into deep sleep. At least we know the whole path is passable, but we don’t know what’s off the path. (r3)

• The Old Forest Road through Mirkwood is overrun by goblins, and has fallen into severe disrepair. (r4)

• The Necromancer is active in the land to the south, near Dol Gildur. Anything could happen, and none of it good. (r5)

Although we don’t have any way of knowing what will happen through any of these areas of Relativity, we know how many of these areas we have to contend with:

• We must pass through the Trollshaws to get to Rivendell, an important stop-over.

• We must go over the Misty Mountains.

• We must go around or through Mirkwood.

The Trollshaws give us 2 Relativity points, no matter what. Next, there are two ways over the Misty Mountains (r3), but the South route means crossing the Gladden Fields too, which adds 3 more Relativity points, so we’ll take the North route.

Next, we must consider how to deal with Mirkwood. The lowest Relativity option is the Elf-path, with a Relativity of 3.

We just chose the safest route using two distinct tactics: (a) minimizing how many tasks contribute Relativity, and (b) favoring options with lower Relativity.

What Is Flux?

Any unknown factor is known as Flux. Each section on our fictional journey map that contains an unknown factor is what I like to refer to as a Flux-Bridge — a hypothetical bridge of unknown length. You have no way of knowing how long a Flux-Bridge is until you cross it; it could be six inches, six miles, or six light-years.

The trick, then, is not to try and guess how long the Flux-Bridges are, which is the shortcoming of most estimation techniques. Instead, you focus on counting how many Flux-Bridges exist on your chosen route.

It’s important to remember that while not every Flux-Bridge will be light-years long, any Flux-Bridge could be. The point is to improve your odds at this game of chance called estimation by minimizing how many Flux-Bridges you have to cross.

The one certainty about a Flux-Bridge is that the route back is almost always predictable. If you discover that crossing is infeasible (r5), you can backtrack and pick a different route.

Borrowing from a different Tolkien story, Gandalf originally meant the Fellowship of the Ring to cross the Misty Mountains at Caradhras. In terms of Quantified Tasks, that option had a lower Relativity, as the route was known and evil creatures were unlikely, leaving only the magical weather as an unknown (r2).

Going through Moria had a much higher Relativity (r4), since they didn’t know the entrance, the darkness would make navigating hard, there were evil creatures abouding, and there was no guarantee that any given route was passable.

Planning aside, once it was clear that the magical weather on Caradhras was going to make that route impossible, Moria — the higher Relativity path — became the better option. The moral here is, despite your best efforts to minimize Flux-Bridges, reality may still force you to contend with the higher-Flux path. Such is the nature of estimation.

Relativity in Release Planning

When selecting Epics and Stories for a Release, we can factor in their Relativity scores in the same two ways:

• Limit how many high-Relativity Epics and Stories we plan for a Release.

• Choose options which minimize Relativity.

Impact and Gravity, the two Quantified Task measures which contribute to Release planning, must be taken into account. These are defined by the product owner and stakeholders (e.g. the client or users). Relativity becomes a key communication tool by which the Developers can influence Release planning.

For example, consider two Gravity 5 Epics: Single Sign-On (SSO) support for an existing user authentication process, and email reminders for unread messages. The Developers look at these two Epics, and determine the following unknown factors:

• SSO Support: Total Relativity 6

  • We need to authenticate with a predetermined SSO provider, which we’ve done in six other product at our company. [Relativity 1]

  • We need a workflow to associate existing user with SSO. This must be designed, as we know very little about what this workflow will look like. [Relativity 4]

  • We need a new button on the login screen for using SSO. [Relativity 1]

• Email Reminders: Total Relativity 11

  • We need to find a solution for sending emails, either pre-packaged or custom-built. We only know what we need it to do, not what options are viable for our product. [Relativity 3]

  • Some users have email addresses, but we don’t know if they’re valid. We also need users without email addresses to add them to their profiles. This requires us to create a new workflow requiring adding and verifying emails. We have a workflow for accepting the Terms of Use, which we may be able to mimic in part. [Relativity 3]

  • At present, we do not have event scheduling, instead taking action (e.g. updating notification icon) when a page is loaded. We will need an event scheduler added, and we don’t know what this will look like. [Relativity 4]

  • Different users will want emails about different messages, so we’ll need to expand the settings with some new fields. We’ve done this before. [Relativity 1]

Just from that initial exploration, we know that SSO Support has five less Relativity points. However, notice that this doesn’t necessarily mean the SSO Support feature will take less time to implement, only that the Email Reminders feature has more uncertainty up front.

Imagining we also have a few bugs that must be resolved in this Release, we may decide that the SSO Support Epic is the feature we develop this time, as it minimizes how much uncertainty we take on in a single development cycle.

Lowering Relativity with Agile Spikes

If our team has a bit of available energy up front, and we know we want to complete both Epics at some point, we may want to lower the Relativity on both through some requirement gathering, design work, and research. In Agile, a Spike is a timeboxed research- or experimentation-oriented task.

In Quantified Tasks, a Spike can sometimes be used to lower the Relativity of a Story or Epic up front.

• Design the workflow for associating an existing user with SSO.

• Evaluate and compare email-sending solutions, with a given budget for an external solution, if desired.

• Design the workflow for validating email addresses.

• Determine requirements for event scheduling.

After these spikes, we have new information.

• The SSO association workflow is completed, but additional uncertainty was determined surrounding forcing explicit SSO reauthentication, to prevent mistakes from associating the account with the wrong SSO. [Relativity 3]

• Of the four email-sending solutions proposed, the team decides to proceed with one of the external solutions; it is within budget, meets needs, and has good documentation and precedence in the product’s tech stack. [Relativity 1]

• The email address validation workflow is completed, and assuming the ability to send emails, is fairly deterministic to build. [Relativity 1]

• The product’s tech stack has a built-in event scheduling system that was previously overlooked. [Relativity 2]

Updating our Epics, we now see that the SSO Support Epic still has a Total Relativity of 6, but the Email Reminders Epic now has a Total Relativity of 5, meaning it now has less uncertainty than the first.

If the organization is wanting to push an update to the product as soon as possible, the Epic with less Relativity may be a better option. The other Epic can be deferred to a subsequent Release, in an effort to keep Relativity to a minimum, and the rest of the developer energy for this Release can be dedicated to fixing some low-Relativity bug fixes and paying down a bit of technical debt.

Relativity, then, allows a team to control for how much uncertainty — and thus, risk — they take on in any given development cycle.

Relativity or Friction?

Remember: Friction is related to our known obstacles, while Relativity is related to unknown factors. You only want to count each factor once in your estimates, and since Friction is linear, and Relativity is exponential, it matters which measure you use to capture a factor! However, multiple factors can also seem to blur together.

For example, some teams struggle to identify whether poor documentation contributes to Friction or Relativity. The answer really depends on why the documentation matters. If the task being estimated on involves a known design pattern, but that pattern is undocumented in the tech stack, this would be a high-Friction, low-Relativity task — lack of knowledge is the only complicating factor.

On the other hand, if a viable design pattern is itself unknown, that contributes Relativity, since the knowledge of how to use different design patterns in the tech stack does not resolve the uncertainty.

A quick way to differentiate between Friction and Relativity is to ask three questions:

• Can we describe one or more solutions in abstract terms?

  • No Solutions: Relativity 4

  • Multiple Solutions: Relativity 3

  • One Solution: Relativity 2

• How confident are we that at least one of the solutions will be viable?

  • Low Confidence: +1 Relativity

  • Moderate Confidence: Same Relativity

  • High Confidence: -1 Relativity

• How many of these solutions are well-known and well-documented in our tech stack?

  • None: Friction 4-5

  • Some: Friction 2-4

  • All: Friction 1-2

The actual Friction score for the task may change when you narrow the field of possible solutions.

Accepting Flux: The Nature of Estimation

As Robert Burns aptly reminds, “The best laid schemes of Mice and Men, oft go astray.” No matter how much we plan, uncertainty still can bite us in the rump. Estimation is still just an educated guess.

Although bridge building scarecely provides a good analogy for software engineering, perhaps another brand of the construction trade is better considered: home renovation. Even best contractor can draw up plans, schedules, and detailed cost estimates, and still have her entire forecast dashed when she opens a wall and finds termines have chewed through the support beams.

This is why, in Energy Points estimation, we take the sum of Distance and Friction and multiply it by Relativity. By exponentially scaling up our estimations, we plan for all Flux to take additional developer energy. Then, if at least some Flux-Bridges turn out to be shorter than anticipated, we can hopefully adjust our budget of developer energy to handle the Flux-Bridges that are taking longer than anticipated. In practice, this helps minimize how far over our estimated delivery dates we actually run.

Even so, sometimes you have to take a step back and rethink. That’s where Agile is so important! Teams must be prepared to adapt their plans to new information. Quantified Tasks is what buys the team that time to adapt, and helps them communicate the causes of delays to stakeholders in a way they can make decisions from.

Often, identifying uncertainty makes all the difference.

You can set up Quantified Tasks with either company-managed projects (strongly suggested!) or team-managed projects.

Option 1: Company-managed Project

If you have access to the system-wide settings for Jira, you should strongly consider setting up Quantified Tasks there. This will ensure that it is used consistently across all company-managed projects.

To access these settings, click the Gear icon in the upper-right, and click Issues.

Issue Types

Select “Issue types”. We strongly recommend the following task types at a minimum:

• Epic

  • Hierarchy Level: 1

• Story

  • Hierarchy Level: 0

• Bug

  • Hierarchy Level: 0

• Task

  • Hierarchy Level: 0

• Subtask

  • Hierarchy Level: -1

If your team prefers to use different names for these, or wants additional types, that is fine. Just understand how your preferred issue types map to these basic types.

Priority = Status

The Priority measure in Quantifed Tasks maps to the Workflow and Status in Jira. The best way to set this up is to create a new Workflow and set it as the active and default workflow for your Jira instance.

Go to “Workflows” and “Add workflow”. Select “Create New” and name the workflow “Quantified Tasks”.

Create the following steps. We recommend allowing free transition between all states, although you may choose to set up transitions if you like.

• pT: Triage

  • Description: Determine priority.

  • Category: To Do

• p0: Backlog

  • Description: Not selected for work.

  • Category: To Do

• p1: Eventual

  • Description: Not currently planned for the current or next sprint.

  • Category: To Do

• p2: Later

  • Description: Will likely be included in next sprint. May be pulled into the current sprint if time permits.

  • Category: To Do

• p3: Next

  • Description: Should be completed in the current sprint.

  • Category: To Do

• p4: Now

  • Description: Currently being worked on.

  • Category: In Progress

• p5: Emergency

  • Description: Reserved for escalating a Task above all other priorities; “drop everything and do this now!”

  • Category: In Progress

• Closed

  • Category: Done

Once you’ve set up your Workflow, go to the “Resolutions” section of Jira admin and ensure you have at least the following resolutions:

• Done: The task satisfies the Definition of Done.

• Superseded: The task is no longer valid.

• Duplicate: The task is a duplicate of another task.

• Cannot Reproduce: Unable to either reproduce issue or determine cause of behavior. Please reopen if more information becomes available.

• Invalid: The premise of the task was flawed from the start.

Next, go to “Workflow schemes” and create a new scheme. Call it “Quantified Tasks”. Select “Add Workflow” and “Add Existing”, then select Quantified Tasks and click “Next”. Check all issue types and click “Finish”.

Gravity = Priorities

Jira’s Priority maps to Quantified Task’s Gravity. You can configure this from the “Priorities” section. You should set these as follows:

• g5: Critical

  • Description: Must be completed, or else the Release cannot ship.

  • Icon URL: /images/icons/priorities/highest.svg

  • Priority Color: #9013FE

• g4: Significant

  • Description: Should be completed. Omit from release if desperate.

  • Icon URL: /images/icons/priorities/high.svg

  • Priority Color: #D0021B

• g3: Major

  • Description: Could be completed. Non-essential, but candidate for inclusion in release if time permits.

  • Icon URL: /images/icons/priorities/medium.svg

  • Priority Color: #F5A623

• g2: Minor

  • Description: Would complete given extra time, but is not slated for current release.

  • Icon URL: /images/icons/priorities/low.svg

  • Priority Color: #F8E71C

• g1: Trivial

  • Description: Won’t complete this release.

  • Icon URL: /images/icons/priorities/lowest.svg

  • Priority Color: #7ED321

Impact

Jira’s Impact field was originally created to track “the effect of an incident on a business' processes”. This makes it reasonably analogous to the Impact measure in Quantified Tasks. To edit this at a global level, go to “Custom Fields”, find “Impact”, and click the three dots at the far end of the row. Select “Contexts and Default value”.

From that page, select “Edit Options”, and modify them to be as follows:

• i5: Massive

• i4: Significant

• i3: Major

• i2: Minor

• i1: Slight

Select “Done”. Now click “Edit context”. Set the Description to: “The importance of a Task to the Solution as a whole, with an emphasis on the effect on users.”

Under “Issue types”, select all types. Click “Modify” to save changes.

Also ensure the default Impact is set to “None”.

Back on the custom field list, find “Impact” again and click the three dots. Click “Associate to Screens”, and select the following:

• Default Screen

• Resolve Issue Screen

• Workflow Screen

If you have other screens that you will continue to use, consider adding it there too.

Click “Update”.

Estimation Measures

The three Estimation measures must be defined from “Custom fields”. For each, click “Create custom field” and create a “Select List (single choice)” field.

• Distance

  • Description: The estimated time to complete if you knew everything.

  • Options:

    • d1: Within day

    • d2: Within quarter sprint

    • d3: Within half sprint

    • d4: Within sprint

    • d5: Exceeds sprint

• Friction

  • Description: Based on available resources to help complete the Task.

  • Options:

    • f1: Highway

    • f2: Street

    • f3: Off-Road

    • f4: Trail

    • f5: Jungle

• Relativity

  • Description: How much uncertainty, or "flux," is in the Task.

  • Options:

    • r1: Trivial Flux

    • r2: Low Flux

    • r3: Moderate Flux

    • r4: Significant Flux

    • r5: Total Flux

Click “Create”. When prompted, assign the custom field to at least the Default Screen and Workflow Screen; consider adding it to any other screens you’ve created to view or edit open issues.

For all three, find them on the “Custom fields” list, click the three dots, and select “Context and Default value”. Click “Edit Context”. Under “Choose applicable issue types”, select the following issue types (Ctrl+Click)

• Bug

• Task

• Story

• Subtask

In the “Custom fields” list, you should also locate “Story Points”. Click the three dots and select “Edit Field”, and change the name to “Energy Points”, then click “Update”. Once again from the list of custom fields, click the three dots and select “Context and Default value”. Click “Edit Context”, and under “Choose applicable issue types”, select the same issue types as with the three estimation measures above.

Back on the custom field list, find “Energy Points” again and click the three dots. Click “Associate to Screens”, and select all your screens. Click “Update”.

Stability Measures

• Origin

  • Description: The phase at which the issue was introduced.

  • Options:

    • o1: Planning

    • o2: Design

    • o3: Implementation

    • o4: Verification

    • o5: Production

• Caught

  • Description: The phase at which the issue was first detected.

  • Options:

    • c1: Planning

    • c2: Design

    • c3: Implementation

    • c4: Verification

    • c5: Production

For both Origin and Caught, we want to set a default value. Find them on the “Custom fields” list, click the three dots, and select “Context and Default value”. Click “Edit Default Value”, and select the highest value for the measure. This ensures that if either is not defined, the Volatility will be high. Then click “Done”.

While still editing “Context and Default value” for each, click “Edit Context”. Under “Choose applicate issue types”, select “Bug” and click “Modify”. This ensures that Origin and Caught only appear on Bugs.

Finally, we need to add a Volatility field. From “Custom fields”, click “Create custom field” and select “Number Field”. Set the name to “Volatility”, and click “Create”. Check the boxes for “Default Screen”, “Resolve Issue Screen”, and “Workflow Screen” — you may also include other screens you use — and then click “Update”.

Automation

To automatically calculate Energy Points and Volatility, from the gear menu in the upper-right corner of Jira, select “System”.

Energy Points

Under Automation, click “Create rule”.

1. WHEN: Field value changed for:

   1. Fields to monitor for changes: Distance, Friction, Relativity

   2. Change type: Any changes to the field value

2. IF: Add a condition

   1. Issue fields condition

      1. Field: Distance

      2. Condition: is not empty

   2. Issue fields condition

      1. Field: Friction

      2. Condition: is not empty

   3. Issue fields condition

      1. Field: Relativity

      2. Condition: is not empty

3. THEN: Add an action

   1. Create variable

      1. Variable name: distance

      2. Smart value: {{issue.Distance}}

   2. Create variable

      1. Variable name: friction

      2. Smart value: {{issue.Friction}}

   3. Create variable

      1. Variable name: relativity

      2. Smart value: {{issue.Relativity}}

   4. Edit issue

      1. Additional fields: (Set to code below)

{"fields": {"Energy Points": {{#=}}{{distance.charAt(1).asNumber}} * {{relativity.charAt(1).asNumber}} + {{friction.charAt(1).asNumber}} * {{relativity.charAt(1).asNumber}}{{/}}}}

Name the automation “Energy Points” and click “Turn it on”.

Volatility

Under Automation, click “Create rule”.

1. WHEN: Field value changed

   1. Fields to monitor for changes: Impact, Origin, Caught

   2. Change type: Any changes to the field value

2. IF: Add a condition

   1. Issue fields condition

      1. Field: Impact

      2. Condition: is not empty

   2. Issue fields condition

      1. Field: Origin

      2. Condition: is not empty

   3. Issue fields condition

      1. Field: Caught

      2. Condition: is not empty

3. THEN: Add an action

   1. Create variable

      1. Variable name: impact

      2. Smart value: {{issue.Impact}}

   2. Create variable

      1. Variable name: origin

      2. Smart value: {{issue.Origin}}

   3. Create variable

      1. Variable name: caught

      2. Smart value: {{issue.Caught}}

   4. Edit issue

      1. More options

         1. Additional fields: (Set to code below)

{"fields": {"Volatility": {{#=}}{{caught.charAt(1).asNumber}} * {{impact.charAt(1).asNumber}} - {{origin.charAt(1).asNumber}} * {{impact.charAt(1).asNumber}}{{/}}}}

Name the automation “Volatility” and click “Turn it on”.

Configuring Your Project

You can now use the configuration with any company-managed Jira project. Create a new company-managed Scrum project, or open an existing company-managed project, and go to the Project Settings.

First, select “Workflow” from the left, and then click “Switch Scheme”. Select “Quantified Tasks” and click “Associate”.

Next, under “Issues” at left, select “Types”. Click “Actions” in the upper-right corner, and select “Use a different scheme”. Select “Default Issue Type Scheme” and click “Associate”.

Still under “Issues” at left, select “Screens”. Click “Actions” in the upper-right corner, and select “Use a different scheme”. Select “Default Issue Type Screen Scheme” (or whatever scheme you’ve set up to work with the new Quantified Tasks fields.) Click “Associate”.

Finally, under “Issues” at left, select “Layout”. Click “Edit Issue Layout” next to your issue types. You can rearrange the layout of issue fields here, but we recommend something like this under Context fields:

• Status

• Assignee

• Sprint

• Distance

• Friction

• Relativity

• Energy Points

• Origin

• Caught

• Volatility

• Impact

• Priority

• Fix versions

• Labels

The main idea is that we’ve grouped fields: Sprint Plan, Estimate, Stability, Release Plan. Of course, you can tweak this to your team’s needs.

Backlog Board Configuration

On your Jira project, go to “Backlog” and click the three dots in the upper-right. Select “Board Settings”, and “Columns”.

Create the following columns and associate the statuses:

• Backlog

  • p2: Later

  • p1: Eventual

  • p0: Backlog

  • pT: Triage

• Selected

  • p3: Next

• In Progress

  • p5: Emergency

  • p4: Now

• Done

  • Closed

Click “Swimlanes” at left. Set “Base Swimlanes on” to “Queries”, add the following Query:

• Name: Emergency

• JQL: status="p5: Emergency"

Click “Add”. This will call out “p5: Emergency” items in a separate Swimlane.

Now click the “Card colors” item at left, and set “Colors based on” to “Priorities”. (This will make the colors reflect Quantified Task Gravity.)

Select “Card layout” at left, and add the following fields to the card layouts:

• Backlog

  • Impact

  • Volatility

• Active sprints

  • Distance

  • Friction

  • Relativity

Finally, select “Estimation” at left, and ensure that “Energy Points” is selected. When you’re done, click “Back to board” in the upper-right.

The End Result

You now have Quantified Tasks fully integrated with your Jira company-managed projects.

There are a few key advantages to this technique:

• The estimation metric is explicitly named Energy Points, and that is automatically calculated from Distance, Friction, and Relativity.

• Quantified Tasks Priority and Status are intrinsically linked.

• Your Jira Priorities directly correspond to Quantified Tasks Gravity.

• Tasks marked “p5: Emergency” show up in their own swimlane.

• Your estimation metrics appear front-and-center on your board.

Option 2: Team-managed Project

If you don’t have control over the Jira instance, or otherwise just want to use Quantified Tasks on specific projects, you can use Team-Managed Projects instead. Although this won’t give you as tight an integration with Quantified Tasks, it will still be good enough for your team to make proper use of the methodology.

For a start, you will need to turn on Estimation in Story points mode. To do this, navigate to Project Settings → Features, enable Estimation, and select Story points. For best results, also enable Backlog, Reports, Sprints, and Releases.

Issue Types

Under Project Settings → Issue types, ensure you’ve defined the following issue types at a minimum:

• Epic

• Bug

• Story

• Task

• Subtask

For Bug, Story, Task, and Subtask, you will want to add the following custom fields. You may be able to add them from your global configuration if you set up company-managed project support for Quantified Tasks, or else you can create them here.

NOTE: If you have also configured the custom fields at a global level, you should append each of these field names with “:” to avoid a name collision that could break automation.

• Dropdown

  • Field name: Impact

  • Display description: The importance of a Task to the Solution as a whole, with an emphasis on the effect on users.

  • Options:

    • i5: Massive

    • i4: Significant

    • i3: Major

    • i2: Minor

    • i1: Slight

• Dropdown

  • Field name: Distance

  • Display description: The estimated time to complete if you knew everything.

  • Options:

    • d1: Within day

    • d2: Within quarter sprint

    • d3: Within half sprint

    • d4: Within sprint

    • d5: Exceeds sprint

• Dropdown

  • Field name: Friction

  • Display description: Based on available resources to help complete the Task.

  • Options:

    • f1: Highway

    • f2: Street

    • f3: Off-Road

    • f4: Trail

    • f5: Jungle

• Dropdown

  • Field name: Relativity

  • Display description: How much uncertainty, or "flux," is in the Task.

  • Options:

    • r1: Trivial Flux

    • r2: Low Flux

    • r3: Moderate Flux

    • r4: Significant Flux

    • r5: Total Flux

Move the “Story point estimate” field that Jira added (from the Scrum template) up to sit below Distance, Friction, and Relativity.

If Priorities were globally configured to map to Gravity (which is strongly recommended!), you can use Jira’s built-in Priority field. Otherwise, you’ll need to create a Gravity drop-down like this:

• Dropdown

  • Field name: Gravity

  • Display description: The importance of a Task in relation to a Release.

  • Options:

    • g5: Critical

    • g4: Significant

    • g3: Major

    • g2: Minor

    • g1: Trivial

Additionally, on the Bug issue type, add these three fields:

• Dropdown

  • Field name: Origin

  • Display description: The phase at which the issue was introduced.

  • Options:

    • o1: Planning

    • o2: Design

    • o3: Implementation

    • o4: Verification

    • o5: Production (set as default)

• Dropdown

  • Field name: Caught

  • Display description: The phase at which the issue was first detected.

  • Options:

    • c1: Planning

    • c2: Design

    • c3: Implementation

    • c4: Verification

    • c5: Production (set as default)

• Number

  • Field name: Volatility

  • Default number: 0

In general, we recommend the following order of context fields (as appropriate):

• Status

• Assignee

• Sprint

• Distance

• Friction

• Relativity

• Story point estimate

• Origin (bug only)

• Caught (bug only)

• Volatility (bug only)

• Impact

• Priority / Gravity

• Fix versions

• Labels

For Epic, the Context fields should be something like the following:

• Status

• Impact

• Priority / Gravity

• Fix versions

• Labels

Statuses

Jira Status maps to Quantified Task Priority. To configure the workflow and statuses, click “Edit Workflow” from any issue type under Project Settings → Issue types.

Create the following statuses:

• pT: Triage

  • Category: To do

  • Allow issues in nay status to move to this one: Yes

• p0: Backlog

  • Category: To do

  • Allow issues in nay status to move to this one: Yes

• p1: Eventual

  • Category: To do

  • Allow issues in nay status to move to this one: Yes

• p2: Later

  • Category: To do

  • Allow issues in nay status to move to this one: Yes

• p3: Next

  • Category: To do

  • Allow issues in nay status to move to this one: Yes

• p4: Now

  • Category: In progress

  • Allow issues in nay status to move to this one: Yes

• Closed

  • Category: Done

  • Allow issues in nay status to move to this one: Yes

At minimum, you should create a transition between “Start” and “pT: Triage”. You can create transitions other if you wish, but in general, we recommend allowing free motion between statuses.

You may also consider creating a few Rules preventing transitioning a task to p3, p4, or p5 without it having a Story point estimate value.

Now click “Update workflow”. When prompted, ensure that all five of your issue types are selected, and click “Save and continue”.

On the “Review columns and statuses on the board” window that appears, create the following columns with the given statues:

• Backlog

  • p2: Later

  • p1: Eventual

  • p0: Backlog

  • pT: Triage

• Selected

  • p3: Next

• In Progress

  • p4: Now

• Done

  • Closed

Click “Save and close”, and then close the Workflow editor.

You will notice that we didn’t create a “p5: Emergency” status! This is because team-managed projects in Jira do not support Swimlanes on Boards. Thus, you should instead create an “Emergency/p5” label that you apply to any “p4: Now” tasks which you want to mark as an emergency.

Automation

To automatically calculate Energy Points and Volatility, from the gear menu in the upper-right corner of Jira, select “System”.

NOTE: If you appended your custom field names with “:” to avoid name collisions with global custom fields, be sure to account for that when creating the rule.

Energy Points

Under Automation, click “Create rule”.

1. WHEN: Field value changed for:

   1. Fields to monitor for changes: Distance, Friction, Relativity

   2. Change type: Any changes to the field value

2. IF: Add a condition

   1. Issue fields condition

      1. Field: Distance

      2. Condition: is not empty

   2. Issue fields condition

      1. Field: Friction

      2. Condition: is not empty

   3. Issue fields condition

      1. Field: Relativity

      2. Condition: is not empty

3. THEN: Add an action

   1. Create variable

      1. Variable name: distance

      2. Smart value: {{issue.Distance}}

   2. Create variable

      1. Variable name: friction

      2. Smart value: {{issue.Friction}}

   3. Create variable

      1. Variable name: relativity

      2. Smart value: {{issue.Relativity}}

   4. Edit issue

      1. Additional fields: (Set to code below)

{"fields": {"Story point estimate": {{#=}}{{distance.charAt(1).asNumber}} * {{relativity.charAt(1).asNumber}} + {{friction.charAt(1).asNumber}} * {{relativity.charAt(1).asNumber}}{{/}}}}

Name the automation “Energy Points” and click “Turn it on”.

Volatility

Under Automation, click “Create rule”.

1. WHEN: Field value changed

   1. Fields to monitor for changes: Impact, Origin, Caught

   2. Change type: Any changes to the field value

2. IF: Add a condition

   1. Issue fields condition

      1. Field: Impact

      2. Condition: is not empty

   2. Issue fields condition

      1. Field: Origin

      2. Condition: is not empty

   3. Issue fields condition

      1. Field: Caught

      2. Condition: is not empty

3. THEN: Add an action

   1. Create variable

      1. Variable name: impact

      2. Smart value: {{issue.Impact}}

   2. Create variable

      1. Variable name: origin

      2. Smart value: {{issue.Origin}}

   3. Create variable

      1. Variable name: caught

      2. Smart value: {{issue.Caught}}

   4. Edit issue

      1. More options

         1. Additional fields: (Set to code below)

{"fields": {"Volatility": {{#=}}{{caught.charAt(1).asNumber}} * {{impact.charAt(1).asNumber}} - {{origin.charAt(1).asNumber}} * {{impact.charAt(1).asNumber}}{{/}}}}

NOTE: If you appended your custom field names with “:” to avoid name collisions with global custom fields, be sure to change "Volatility": in the code above to "Volatility:":

Name the automation “Volatility” and click “Turn it on”.

The End Result

This should be enough to use Quantified Tasks with your team-managed project. Although it doesn’t have as tight an integration with the methodology as a company-managed project does, it works pretty well. (I’ve run a large project this way myself!)

Feedback Welcome!

If you have any questions or suggestions for improvement on using Quantified Tasks with Jira, please leave a comment. Happy issue tracking!

We recommend using the Table with Tasks. One of the best advantages of Monday.com for Quantified Tasks is the fact that averages and sums are automatically shown for each group of Tasks.

Setting Up

To get started, add the following Status columns:

• Impact

  • i5: Massive

  • i4: Significant

  • i3: Major

  • i2: Major

  • i1: Slight

  • iT: Triage (default)

• Gravity

  • g5: Criticcal

  • g4: Significant

  • g3: Major

  • g2: Minor

  • g1: Trivial

  • gT: Triage (default)

• Priority

  • Done (indicates done)

  • p5: Emergency

  • p4: Now

  • p3: Next

  • p2: Later

  • p1: Eventual

  • pT: Triage (default)

• Distance

  • d1: Within day

  • d2: Within quater sprint

  • d3: Within half sprint

  • d4: Within sprint

  • d5: Exceeds sprint

  • dT: Triage (default)

• Friction

  • f1: Highway

  • f2: Street

  • f3: Off-Road

  • f4: Trail

  • f5: Jungle

  • fT: Triage (default)

• Relativity

  • r1: Trivial Flux

  • r2: Low Flux

  • r3: Moderate Flux

  • r4: Significant Flux

  • r5: Total Flux

  • rT: Triage (default)

• Origin

  • o1: Planning

  • o2: Design

  • o3: Implementation

  • o4: Verification

  • o5: Production

  • o0: Not a Bug

• Caught

  • c1: Planning

  • c2: Design

  • c3: Implementation

  • c4: Verification

  • c5: Production

  • c0: Not a Bug

Order these columns however you like. We recommend adding Descriptions to each to help your team remember how to use the different Measures. We additionally recommend the following colors:

• 1: Green

• 2: Yellow

• 3: Orange

• 4: Red

• 5: Purple

• T/0: Gray

Once you’ve created these Status columns, add two Formula columns with the following formulas:

• Energy Points

  • (RIGHT(LEFT({Distance},2),1) + RIGHT(LEFT({Friction},2),1)) * RIGHT(LEFT({Relativity},2),1)

• Volatility

  • (RIGHT(LEFT({Caught},2),1) - RIGHT(LEFT({Origin},2),1)) * RIGHT(LEFT({Impact},2),1)

• Pending

  • IF({Priority}="Done",0,{Energy Points})

• Velocity

  • IF({Priority}="Done",{Energy Points},0)

Energy Points will always display a warning when there is no estimate (Distance, Friction, and/or Relativity is set to Triage), but this behavior is desirable.

Volatility will always display a value, as the default score is 0.

Task Types and Fields

In this document, a Task may refer to any single work item, including a Story, Issue, Bug, Feature, or Task. Each Task must support the following fields (more details later in article):

• Assignee,

• Impact (1-5 drop-down),

• Gravity (1-5 drop-down), likely maps to built-in Urgency/Priority field,

• Priority (1-5), likely maps to Status,

• Distance (1-5 drop-down),

• Friction (1-5 drop-down),

• Relativity (1-5 drop-down),

• Energy Points (numeric), likely maps to Story Points.

Issues (a.k.a. bugs) should additionally have the following fields:

• Origin (1-5 drop-down),

• Caught (1-5 drop-down),

• Volatility (numeric).

Subtasks rarely have any of the above.

Epics should only have the following:

• Impact (1-5 drop-down); optionally, you can call this Epic Impact if necessary,

• Gravity (1-5 drop-down).

Priority = Status

Priority maps to Kanban columns or the status field in most trackers. If you can edit the names of the statuses, we recommend using something like the following:

• Backlog (pT-p1). You may also hide these tasks from your board.

• Next Sprint (p2)

• Next/Selected for Development (p3)

• Now/In Progress (p4-p5)

• Done

You should add a flag or label for “Emergency (p5)” to call those Tasks out from the p4 Tasks in the Now column.

Impact

The Impact field should be a custom drop-down field, as Impact is distinct from Gravity (discussed below). Be sure to add this field to both Tasks and Epics.

If you like, you may define a separate Epic Impact field for Epics.

Gravity = Urgency/Priority

The "urgency" or "priority" field on most trackers maps to the concept of Gravity. (Yes, this is confusing until you're used to it.) If you can edit the names of the urgency or priority options, we recommend the following:

• g5: Highest/Critical

• g4: High

• g3: Medium

• g2: Low

• g1: Lowest/Trivial

• gT: (No Value)

If you're using Jira, you may already have five possible values under their "Priority" field that you can equate to Gravity scores.

Distance, Friction, and Relativity

If you have tags, labels, or custom fields, add the five values for each of these three measures. These should be added to Tasks, but not Epics.

If you cannot add custom fields, you should type out the full formula for your Energy Points at the top of each task description. For example, (d3 + f2) * r2 = 10 might appear in your description, while just 10 goes in the Story Points field.

• Jira, Trello, and Phorge/Phabricator (among others) have custom fields on tasks, so add fields for Distance, Friction, and Relativity.

• GitHub and GitLab (among others) support arbitrary labels. These should look like d3: Half Sprint or f4: Trail for easy reading and quick adding.

Energy Points <-> Story Points

The Energy Points score belongs in the Story Points field, which most trackers have. For example, Jira and Phorge have Story Points, while GitLab Premium has Weight.

Issue trackers with automation can be configured to calculate Energy Points automatically from Distance, Friction, and Relativity.

Stability Measures

Origin and Caught are best specified with custom fields, and Volatility with a custom numeric field. Barring this, include them in the description instead.

Automation can be used to auto-populate a custom numeric Volatility field from Origin, Caught, and Impact.

Tracker-Specific Patterns

Share Your Usage Patterns!

If you have any patterns you'd like to share, please comment!

Additionally, if you are a designer or developer on an issue tracker, and you add support for Quantified Tasks, let us know! We want to spread the word.

Leave a comment

A Trip to the Store

Consider a shopping trip to the grocery store in preparation for a party. You have a list of items and a budget. Notice what we don’t consider: the number of transactions, the size of the shopping cart, or the number of shoppers. Why? Our limiting factor is our budget, and our goal is to purchase everything on the list. Adding more shoppers or using larger shopping carts will not change that budget.

Once you have identified your limiting factor, you can either take a predictive or an adaptive approach to planning your shopping trip.

The predictive approach is to try to guess how much all the items on your list are going to cost. Assuming you don’t have the option of looking up the prices online, you’re going to have to make your best guess using knowledge of prior shopping trips, maybe some old grocery receipts, and awareness of how prices have changed recently.

The adaptive approach is to write a list of the items you want to purchase, and determine your budget for the trip. That budget is normally dictated by external factors, and not by the items on your list. You would probably also prioritize your shopping list, so if you find your budget isn’t sufficient to cover everything, you can easily determine what to skip.

Often, you’d take some sort of hybrid approach that combines both techniques. Knowledge of prior shopping trips and market rates may help you write a realistic shopping list, and then you can iterate on this list once you’re at the store.

Which approach makes more sense for your shopping trip? It depends on the situation. Regardless, if you don’t know your budget, none of these techniques will work!

What Do We Measure?

In software estimation, we deal with finite resources as well, such as financial budgets and time constraints. Starting our thinking from these is dangerous, however, because neither directly correlates to how many items on a list of software development goals we can complete.

The real limiting factor in software development is Developer Energy. Human beings have a limited amount of cognitive energy each day and each week, and once that is exhausted, the quality of their work diminishes significantly. (This is a major reason why the adage “never ship on Friday” exists; errors are more likely at the end of the workweek.) One cannot overcome this limit by simply demanding overtime or paying additional money

That is not to say that time and money cannot be used to increase Developer Energy. You may eliminate unnecessary meetings to free up Developer hours, or add additional headcount (while taking Brooks’s Law into account.) These are merely ways of expanding your “energy budget,” but Developer Energy is still the limiting factor. Once a Developer is “out of gas”, you’re not getting any more work out of them until they recharge in whatever manner they need to.

Once we have identified the limiting factor as Developer Energy, we can begin the task of software estimation. Unlike traditional story pointing, the Quantified Tasks methodology actually provides a technique for repeatably measuring, tracking, and estimating the developer energy budget.

How Do We Measure?

The problem with traditional Agile Story Points is that they only indirectly measure the Developer Energy required. It’s a bit like going to the store with no clear budget, but a vague sense that the ice cream will cost twice as much as the coleslaw. What’s worse, because the amount of effort a Story Point represents varies from team to team and project to project, you have no frame of reference when planning effort on a brand-new project. It’s as if every grocery store lists prices in its own original currency.

By contrast, Energy Points in Quantified Tasks are an objective, repeatable unit of Developer effort. Instead of translating an arbitrary assessment into (say) a Fibonacci number, Energy Points are calculated from three objective 1-5 scores:

• Distance: raw effort if you knew everything about the task,

• Friction: available resources to inform the task, or the lack thereof, and

• Relativity: how much uncertainty exists in the task.

Any two Developers may have different ideas about how “big” or “hard” a task is, depending on their experience level and other factors, but it is fairly easy for everyone to agree on a score for each of these three measures.

Energy Points are calculated via the formula (Distance + Friction) * Relativity. This estimate is thus defensible, as each of the three factors are objective, and it bears the authority of team consensus. Not only this, but because it is based on three predefined, fixed metrics, the Energy Points estimate can be compared directly to any other task from any other project or team using Quantified Tasks.

Energy Points thus represents how much Developer Energy is needed to complete the task.

Budgeting Developer Energy

Given Energy Point estimates on every task, we are now only missing one piece of information: how much Developer Energy do we have? What is our budget?

Every Developer is a unique individual. They will have different strengths, weaknesses, and experiences. Thus, for a Developer who is brand new to Quantified Tasks, it will be difficult to guess how many Energy Points they can complete in a sprint. However, after only one or two sprints, each Developer will begin to form an understanding of how much work they can complete under the circumstances.

For example, as a Principal Software Engineer in Python, I found I could complete an average of 25 Energy Points per sprint. It did not matter what the project was — as long as it was a Python-based stack, that estimate held true. If I was not proficient in the language, I could complete about 10-15 Energy Points in a sprint. Thus, I was able to select work for myself during Sprint Planning, and nearly always complete that work by the end of the sprint. (Estimates are exactly that — estimates.)

What’s further, Developers can use Distance, Friction, and Relativity to select work appropriate to their experience level. Someone brand new to a language should probably avoid taking on a high-Friction task, while someone who is more senior in that language should try to leave some of the easier work to the less experienced members of the team. Although two tasks with the same Energy Point estimate require roughly the same amount of energy, different Developers can handle different styles and cadences of effort.

As a Developer begins to track their Personal Velocity (the average Energy Points completed per sprint), it will become easier to set realistic goals for sprints and releases.

Measuring Developer Productivity

Energy Points not only allow you to estimate effort, but they can also serve as a reliable metric of how much work was completed. As long as the Quantified Tasks methodology is applied correctly by the team, and scores are updated as more information is learned, Personal and Team Velocity become good representations of Developer productivity.

There are a few things to be aware of with this, however, including:

1. Each Developer has a unique, fixed energy budget. This can be further impaired by external factors. Use Velocity as an indicator to trigger further inquiry, never a goal to be met.

2. Be wary of comparing Personal Velocity across Developers. No two people are identical, even if they have the same seniority and experience level.

If you want to use Quantified Tasks to measure Developer Productivity, please see this article:

Getting Started with Quantified Tasks

If you want to get started using Quantified Tasks with your team or company, check out the Overview.

Please also subscribe to get the latest articles and updates delivered right to your inbox!

Subscribe now

• Counting lines of code written encourages writing complicated code, and doesn't reward Developers for improving efficiency and code health, which will typically result in negative line counts.

• Counting shipped features discourages Developers from paying down technical debt and maintaining legacy systems, as such work becomes invisible and thankless.

• Counting fixed bugs encourages creating bugs. (As Wally in “Dilbert” said, “I’m going to write a new minivan!”)

• Counting hours worked punishes efficiency and encourages overwork and poor time management.

• Counting closed tasks makes no differentiation between easy tasks and hard tasks. A Developer who closes a dozen easy frontend fixes looks better in this light than the one Developer that developed an innovative AI model to respond to search requests.

• Counting story points never made sense, because who can say what one story point is even worth?

There have even been some recent attempts at solving this which have proven naïve and ill-informed, as Kent Beck and Gergely Orosz recently pointed out:

The Pragmatic Engineer

Measuring developer productivity? A response to McKinsey

👋 Hi, this is Gergely with the monthly, free issue of the Pragmatic Engineer Newsletter. In every issue, I cover challenges at Big Tech and startups through the lens of engineering managers and senior engineers. Subscribe to get two full issues every week. Many subscribers expense this newsletter to their learning and development budget. If you have suc…

Read more

3 years ago · 397 likes · 17 comments · Gergely Orosz and Kent Beck

The question remains, how do we measure Developer productivity and accomplishment?

Quantified Tasks provides the first reliable, objective method of estimating and measuring how much Developer energy is needed to complete a task. (Read more.) Meanwhile, Impact and Gravity help align priorities to stakeholder needs. All of these provide insight into Developer effort and outcomes.

Because these scores are defined on tasks from sprint to sprint, they provide insight much earlier than periodic employee reviews or surveys. Better still, if a team is properly using Quantified Tasks, their estimates serve as leading indicators of project and team health. Not only can these provide valuable insights into Developer performance, but they also serve as a communication tool between Management and Developers.

Although this data is only part of a larger picture, Quantified Tasks represents a leap forward in measuring development work.

A Few Warnings

While Quantified Tasks provides a more accurate and nuanced system of measuring accomplishment, caution on the part of the Manager is warranted on a few fronts!

Implementing Quantified Tasks

Quantified Tasks is primarily a tool for estimation and planning, and it must be embraced by the team before it will provide useful productivity insights. You can verify that teams are using the methodology correctly by ensuring that estimates are reasonably accurate (remembering that estimates are still estimates), and that sprints and releases are being completed in alignment with the Planning measures (Impact, Gravity, Priority) and the actual business and stakeholder needs.

For example, if a conscientious Developer spends a sprint mitigating an unforeseen security issue that could have cost the company millions if unresolved, but that security issue was never properly identified as having a high Impact, it may appear that the Developer’s priorities were out of line.

Similarly, if a team originally estimates too high, but their estimates become more realistic as they become familiar with Quantified Tasks, their Velocity will appear to come down. This could be mistaken for a decrease in effectiveness until one realizes that they’re learning the methodology.

Respecting Goodhart’s Law

"When a measure becomes a target, it ceases to be a good measure.” -Goodhart’s Law

If Managers disregard Goodhart’s Law and define targets for Quantified Task measures (especially Energy Points and Velocity), there is a very real temptation for teams to artificially inflating scores.

Instead, utilize the totals and averages of these measures as a starting place for assessing performance. For example, rather than requiring that a Developer complete a minimum of 40 Energy Points per sprint, thereby destroying the usability of that as an estimation tool, a good Manager will instead take notice that a Developer is trending higher or lower from their average, and investigate why.

Every Developer needs to be able to form a personal relationship to the Estimation measures, especially Energy Points. This means that direct comparison between Developers are seldom appropriate, and never for evaluating performance. A Developer must only ever need to “compete” against themselves, and external factors like life circumstances and familiarity with the tech stack must be taken into account.

In short, both Team and Personal Velocity must only be part of a larger picture.

Measures as Performance Metrics

Most of the measures in Quantified Tasks can be used as raw productivity metrics. Again, by “raw,” I mean that the metrics provide clues for where further inquiry is needed.

Impact

The total Impact of tasks completed by a Developer indicates how much user value they've provided, based on the impact analysis performed by the Product Owner and Stakeholders.

The average Impact indicates the alignment of the Developer’s work to Stakeholder goals. Remember that Developers are only supposed to work on tasks which have been identified as part of the Release (Gravity) and Sprint, so if there is poor alignment, Managers must confirm whether Release and Sprint planning were properly aligned to Impact.

Gravity

The total Gravity of tasks completed by a Developer indicates how much value they contributed to the Release.

The average Gravity indicates how much alignment there was between the Developer’s work and the goals of the Release.

Remember that Priority and Gravity are necessarily distinct concepts. For example, several g3 tasks may have been needed before a g5 task could practically be implemented.

Energy Points

Energy Points indicate how much work was completed. Every Developer can complete a different number of Energy Points depending on their seniority, skill level, and familiar with the project and technology. The number of Energy Points a Developer completes in a sprint is their Personal Velocity.

For this to work, all effort on a project MUST contribute to Velocity. This means all design, testing, documentation, code review, and deployment work (etc.) should be tracked as tasks with accurate assignments and estimates. It’s common for such “non-implementation” tasks to be left off the issue tracker, which creates the illusion that less work is being done. For example, a Senior Developer may spend eight hours a week code reviewing colleagues — an important and productive part of any development team’s workflow — but that work is seldom included in the issue tracker. Thus, the Senior Developer’s Personal Velocity, and the Team Velocity along with it, will appear to be lower than it actually is.

When Quantified Tasks is properly implemented, Personal Velocity can reveal a Developer's increasing skill over time, but only if compared against their own past performance, with external factors considered. Every Developer is unique, so comparison between co-workers, even at the same experience level, is strongly discouraged.

The one exception to this is in monitoring the average Personal Velocity of everyone on the team, and comparing that to the Personal Velocity of a single Developer. When a Developer’s Personal Velocity is consistently above the average, this can be a strong indicator that the they are overworked, and may be in danger of burnout.

Similarly, if their Personal Velocity dips well below either their own average or that of the team, this may indicate that external tasks or other factors may be diverting their attention from the project. Again, there may be valid causes for this — onboarding new team members, participating in meetings, or dealing with external factors. Everyone’s personal best will also change from week to week, depending on life circumstances. However, a severe or sustained dip may warrant further curiosity.

Distance

The total Distance of tasks completed by a Developer is a raw measurement of effort, apart from research and experimentation. Remember, Distance measures how much effort is involved if the Developer knew everything about the task and the technology involved, so this total will not include effort for research, experimentation, or learning.

Friction

The average Friction of tasks completed by a Developer indicates the complexity of the work they completed. Higher Friction indicates that a task objectively involves more research and experimentation. A high average Friction would mean the Developer probably untangled some difficult problems.

When a Developer demonstrates an upward trend in average Friction from sprint to sprint over time, it may be a good indicator they are ready to move on to a higher seniority level. When monitoring this, be sure to factor in the total and average Friction of each sprint.

Relativity

The total Relativity of tasks completed by a Developer indicates how much uncertainty, or "flux," their work involved. Higher flux makes for more challenging work. As with Friction, an upward trend here may be a good indicator of increasing experience.

Be advised, however, an increase in Relativity across a project is a likely indicator that business analysis and software engineering activities have seen a drop in effectiveness. If this trend goes unaddressed, your team may be headed for burnout, and the project is likely to stall.

Using the Metrics

As Kent and Gergely pointed out in their article, it is not enough to simply measure a Developer’s work output. Even Quantified Task metrics are only part of a larger picture.

The Pragmatic Engineer

Measuring developer productivity? A response to McKinsey, Part 2

👋 Hi, this is Gergely with a bonus, free issue of the Pragmatic Engineer Newsletter. In every issue, I cover challenges at Big Tech and startups through the lens of engineering managers and senior engineers. If you’re not yet a full subscriber, you missed issues like…

Read more

3 years ago · 147 likes · Gergely Orosz and Kent Beck

To recap:

• Quantified Tasks must be properly implemented, continuously validated, and functioning as a reliable estimation and communication tool, aside from measuring productivity. If it isn’t useful for planning, it is worthless for insight.

• All work on the project must be tracked and estimated, to ensure it contributes to Velocity. Otherwise, Velocity is an incomplete and inaccurate picture.

• A good Manager will consider all metrics both on a personal and team level.

• Impact alignment is just as important as Velocity.

• The alignment between Impact, Gravity, and validated user value should be routinely verified.

Quantified Tasks provides some promising tools for measuring Developer productivity and accomplishment. It is still only a part of a larger picture, so I recommend reading the following as well:

The Pragmatic Engineer

A new way to measure developer productivity – from the creators of DORA and SPACE

👋 Hi, this is Gergely with a bonus, free issue of the Pragmatic Engineer Newsletter. In every issue, I cover challenges at Big Tech and startups through the lens of engineering managers and senior engineers. If you’re not a subscriber, you missed the issue on…

Read more

3 years ago · 315 likes · 3 comments · Gergely Orosz

Getting Started with Quantified Tasks

If you want to get started using Quantified Tasks with your team or company, check out the Overview.

Please also subscribe to get the latest articles and updates delivered right to your inbox!

Subscribe now

Shared Benefits

The real benefits of Story Points are also shared by Energy Points:

• Relative: Task A is larger (requires more effort) than task B.

• Objective: Developers can discuss and agree on points based on observable attributes of the task, regardless of their individual skill.

• Unitless: The point system is not mapped to existing units of time or money, thus resisting (but not utterly preventing) efforts to interpret points as budgets or commitments.

• Measuring velocity: Both systems of points can be used for measuring and predicting team velocity and generating things like burndown charts.

• Persistent: Tasks don't have to be re-estimated frequently (unlike time-based estimates). Under either system of points, it may still be necessary to adjust if additional complexity is discovered.

• Collaborative: Scoring is done as a team. Either point system can be used in Planning Poker.

What About Fibonacci?

Fans of Fibonacci-based Story Points insist that having a non-linear increase of subsequent point values is essential.

The main reason cited is that, with increased complexity comes increased uncertainty. This is represented by having larger gaps between each subsequent level of complexity. Energy Points does not need this compensation, however, as uncertainty is baked in via the Relativity measure. The higher the Relativity, the larger the gaps become as complexity grows.

In fact, Energy Points covers almost the same range of values as Fibonacci-based Story Points. When you only consider Relativity scores 1-4 (since 5 is typically a warning sign), Energy Points spans values 1-40, while Fibonacci Story Points spans 1-55, or 0-40 if you're using the common modified form. Additionally, less than half the values in either system are less than 11, while only approximately 11% of values are greater than 30.

One other reason Fibonacci is brought up is that it's a "natural" progression of numbers. While this is a factual statement, it is something of a "sacred geometry" misconception when it comes to estimation. The very fact many teams modify the sequence to make it work better for estimation proves the point. After all, what's stopping us from using the exponents of the Mersenne primes instead (2, 3, 5, 7, 13, 17, 19, 31...)?

However, if you really, really cannot bear to part ways with Fibonacci point scores, you can just use the closest value to the Energy Score. Since the distributions are similar, as long as you record your Distance, Friction, and Relativity, which are also useful by themselves, you don't lose the advantages of Energy Points.

Unique Advantages of Energy Points

There are a couple of flaws with Story Points that Energy Points overcomes:

Story Points are inconsistent between teams, and point values can even change meaning as the composition of the team changes. This invalidates the usefulness of points on tasks estimated by other teams, or even earlier iterations of the current team.

In contrast, Energy Points are calculated from three standardized measures, so relative "sizes" of tasks are consistent even across teams, and individuals can understand their own personal capabilities in relation to Energy Points.

The second problem with Story Points is that they discard relevant information, particularly related to what factors are contributing to a task's size. In Story Points, two tasks may both be sized as "8", but one is merely a long, repetitive task, while the other involves developing a new algorithm. While this information should be captured in the task description, in practice, most teams don't excel at writing descriptions that succinctly express all relevant information.

With Energy Points, two tasks may still have a score of "8", but the three contributing measures serve as a "TL;DR" of the essential properties of the task. The long, repetitive task is (d3+f1)*r2=8, while the one involving developing a new algorithm is (d1+f3)*r2=8. This aids in allocating work, and guides further conversation and description.

Getting Started with Quantified Tasks

If you want to get started using Quantified Tasks with your team or company, check out the Overview.

Please also subscribe to get the latest articles and updates delivered right to your inbox!