This article describes what “Probability rates of completion Scope for Burn-up/Burn-down” metric is and how it helps and works
...
Table of Contents | ||||
---|---|---|---|---|
|
Creating a metric
See Custom Metric development for details
...
Further will be the explanation of the code you should put in the “PerfQL” field
Introduction
We want to build a metric that is capable of predicting the probability of scope completion in several future iterations. In other words if we have two curves describing growth of the scope and the amount of tickets in “done“ status we want to know the probability of crossing these curves in the future.
...
To do so we will use the data about scope and done curves for every iteration in the past and normal distribution law as one of the most widespread law for many processes in the world. Now let’s explore the sql-query calculating required probabilities.
Fill the required parameters
...
Code Block | ||||
---|---|---|---|---|
| ||||
variables as (
select
'tickets' 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
) |
...
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 ‘tickets(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.
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.
iterations_to_analyze: type here a number of previous iterations including current one to use their data in the analysis.
future_iterations_num: the number of iterations to be shown in the chart with related probabilities.
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.
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).
ticket_type: this is the list of types defining what types the tickets we retrieve with our query must have 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
Code Block | ||
---|---|---|
| ||
start_date_ as ( select date_trunc('week', current_date)::date - (select iterations_to_analyze*iteration_duration from variables) as start_date ) |
...
Code Block | ||||
---|---|---|---|---|
| ||||
disp_in_disp_out as ( select day_, scope, done, added_in, velocity, AverageIn, (sum(case _in_disp_out as ( select day_, when scope, done, n <= 0 then (added_in - AverageIn)*(added_in - AverageIn), velocity, AverageIn, end coalesce( ) over ()(sum(case when ) n <= 0 / then (select -n-1 from iteration_end_dates_ order by n limit 1) as disp(added_in, --sigma(2) AverageIn)*(added_in - AverageIn) AverageOut, end ) over () (sum(case )/nullif((select -n-1 from iteration_end_dates_ order by whenn limit 1), 0), 0) as disp_in, --sigma(2) n <= 0 AverageOut, coalesce( then (sum(case (velocitywhen - AverageOut)*(velocity - AverageOut) n <= 0 end then ) over () (velocity - AverageOut)*(velocity - AverageOut) ) end ) over () / )/nullif((select -n-1 from iteration_end_dates_ order by n limit 1), 0), 0) as disp_out, n from avg_in_avg_out ) |
Example of the output:
...
Expand | |||||
---|---|---|---|---|---|
|
...