Introduction

The “The earliest date by which the work could

conceivably be done makes an excellent goal but

an awful schedule.”

Tom DeMarco, Slack: Getting Past Burnout, Busywork,

and the Myth of Total Efficiency

This metric predicts the probability of scope completion using Normal (Gaussian) distribution and math statics.

One of the biggest problems for a project manager is to understand when scope can be accomplished. It’s especially hard in the real-world environment. For instance with constantly changing team performance, floating scope, various types of work.

This metric analyze analyzes statistic of “added” work vs “done” work by short iteration and predict probability of crossing of these trends using Normal Cumulative Distribution.

...

Jira type of work– bugs, stories, epics, etc.
NoEstimate vs Estimate– calculation based on number of tickets or story points
Scope change– take into account or ignore scope change statistics
Iteration duration– length of iteration to analyze in days
Iterations to analyze– statistics of how many iterations will be taken for analysis
Future iterations number– for how many iterations it predicts probability

Creating a custom metric

See Custom Metric development for details

...

variables as (
select 
        't' as calculate_by,      -- choose the basement of calculation: tickets or story points 
        7    as iteration_duration,     --in days
        20   as iterations_to_analyze,
  		20   as future_iterations_num,  --number of iterations to make forecast for
  	    'no' as scope_change,           --yes/no
  		200  as division_step           --must be an even number!
),

types as (
select  a.* from (values ('bug'), ('task')) a (ticket_type) -- add ticket types to make forecast
)

1. calculate_by: metric calculation can be based on two types of data - tickets and story points. If there’s a need to make forecast by tickets type (exactly!) ‘t' before “as calculate_by“ (third row in the code snippet above). If it’s not - type any other word/symbol in quotation marks instead.

2. iteration_duration:the timeline in the metric is divided into weeks, so this parameter is set to 7 days and there’s no need to change it.

3. iterations_to_analyze: type here a number of previous iterations including current one to use their data in the analysis.

4. future_iterations_num: the number of iterations to be shown in the chart with related probabilities.

5. scope_change: this parameter defines if we add tickets or story points to the scope in the future or not. If not - type 'no' before “scope_change“, else - type any other word/symbol in quotation marks before “scope_change“ instead.

6. division_step: this parameter helps to change the accuracy of calculations. The higher the number, the higher accuracy we can get. Also this number must be even and shouldn’t be too high to slow code down too much (for our purpose to get two decimals after floating point 200 is enough).

7. ticket_type: this is the list of types defining what types the tickets we retrieve with our query must have. To add new ticket type to the calculation type it in single quotes and parentheses in “values“ clause. Parts of “values“ clause must be separated by commas.

Start date

start_date_ as (
select date_trunc('week', current_date)::date 
- 
(select iterations_to_analyze*iteration_duration from variables) as start_date
)

...