This article describes what “Probability rates of completion Scope for Burn-up” metric is and how it helps and works
...
Introduction
“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 analyzes statistic of “added” work vs “done” work by short iteration and predict probability of crossing of these trends using Normal Cumulative Distribution.
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 achieve that the metric analyzes average of scope changes and done work, and standard deviation for them. The probability is calculated by the following formula:
...
The metric uses following main parameters:
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
Table of Contents | ||||
---|---|---|---|---|
|
Creating a custom metric
...
Creating a Custom Selection
See Custom Metric development to see how to get to a Custom Selection mode.
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.See Custom Metric development for details
Creating a Custom Selection
See Custom Metric development to see how to get to a Custom Selection mode.
Further will be the explanation of the code you should put in the “PerfQL” field
Fill the required parameters
...
Code Block | ||||
---|---|---|---|---|
| ||||
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 ) |
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.
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. 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 | ||
---|---|---|
| ||
simpson_rule as ( select day_, scope, done, n, work_left, me, sd, points, h, index, case when index = 1 or index = (select v.division_step from variables v)+1 then normal_dist_value when mod(index, 2) = 0 then normal_dist_value*2 when mod(index, 2) = 1 then normal_dist_value*4 end as simpson_values from normal_dist_values ) ) select to_char(day_, 'yyyy')||' - '||todate_charpart('week', day_, 'ww') as week_number, round((max(h)::numeric/3)*sum(simpson_values)::numeric*100, 2) as probability from simpson_rule group by day_ order by day_ |
Example of the output:
...
Full code recap
Expand | |||||
---|---|---|---|---|---|
|
...