Stability is a measure of the volume of requirement change during a sprint expressed as a percentage of change vs plan.

Stability highlights the ability of a team to work with a stable set of requirements during a sprint as we see lower Completion Rates when Stability is lower .
​

Umano measures Stability through calculating:

A score of 100% means that the sprint was executed as planned without updates to requirements or new work.

Identify the number of tickets that have a time estimate, story point estimate and tickets with no estimate.

Step 2:

Using data from each team over a period of time (usual cycle time (6 intervals)) calculate the average time taken to complete a unit estimate or average time taken to complete a task with similar estimates. When there is no statistic estimate assigned for a ticket, use past similar tickets to predict the estimated time it would take to complete the ticket so that there is a common weighting that is valid for all tickets in the sprint.
​
​

Step3:

Use the computed time estimates as weighting calculate the stability impact for each ticket in the sprint.
​

This is a measure that entirely depends on your team’s context.

A core principle of applying the agile method is that teams welcome change in requirements, even late in development. As such, changing requirements may reflect legitimate shift in priorities, or a response to discoveries that require a change in approach. It can also be reflective of a team’s adaptability in responding to the changing needs of their product manager or customer.

Unstable requirements during a sprint however may be the result of insufficiently planned work. This phenomenon can also be referred to as scope creep and is closely linked to increases in costs and projects going over budget.

Stable requirements provide a team with a stable goal (fixed scope) to work towards. This can build confidence and lead to a team being able to ship features more predictably.
​

Your team’s context is the best arbiter of what ‘good’ looks like for your team.

When a team focuses on improving their speed or progress, higher levels of stability are favoured over lower but 100% stability usually isn't the goal unless you have very predictable work. Use Umano to manage the expectations of your team and peers with a clear eye on the assigned tasks and work with your Product Manager to document and requested changes so they can be reviewed and prioritised when planning for your next sprint.

If your team has prioritised being responsive to customers, lower levels of stability can be expected.

Look out for patterns that don't match your expectations relating to constantly changing requirements over time. This can be reflective of not enough time spent planning, or breaking down stories relating to the sprint goals into smaller, better understood tasks. This pattern can lead the team to feeling like they are ‘spinning wheels’, lacking in a sense of completion and progress. Changing requirements may also have a greater impact on a team the later that the changes are made.

Tips for a more stable sprint

Step 1:

Identify the number of tickets that have a time estimate, story point estimate and tickets with no statistics estimate.

N = Total number of tickets in the sprint

Step 2:

Using data from each team over a period of time (usual cycle time (6 intervals)) calculate the average time taken to complete a unit estimate or average time taken to complete a task with similar estimates. When there is no statistic estimate assigned for a ticket, use past similar tickets to predict the estimated time it would take to complete the ticket so that there is a common weighting that is valid for all tickets in the sprint.

T = Time estimated for the whole sprint

Estimating time taken per story point/unsized tickets can be done in multiple ways depending on the amount of data available per project/team (as estimation practices can vary from project to project and overtime):

Step 3:

Use the computed time estimates as weighting calculate the stability impact for each ticket in the sprint.

Notes:

We also disregard the time it takes but assign no estimate tasks a story point depending on the usual cycle time and use story points as weights instead of the time.

This can be useful when there are story points that have irregular usual cycle times.
​
​

Sprint start date: 2019-01-07 10:00:00

Sprint end date: 2019-01-10 17:00:00

Sprint on the first day (2019-01-07):

​
​

Step 1:

nt = 1

ns = 3

nn = 1

(Total number of tickets in the sprint) N = 1+3+1 = 5

Step 2:

t = 1s

Tt = 1200 * 1s = 1200s

us = Assume in the past to complete a story point it has taken 12mins on average
us = 12*60 = 720s

Ts = 720*1 + 720*4 + 720*2 = 5040

Assuming all the bugs belonging to this project with testing in the title has taken 2 hours on average to complete,

ue = 2*60*60 = 7200s

Tn = 7200s

(Total time in the sprint at the start) T = 1200 + 5040 + 7200 = 13440s

​
​

Sprint on the second day (2019-01-08):

Stability of the sprint on 2019-01-08:

(Test changes are calculated using difflib)

Change in ticket xx-0002:

Changes to acceptance criteria = (Test this accept .... → Test acceptance criteria 2) = 0.4893617021276596

Total changes in xx-0002 = (summary_changes + acceptance_criteria_changes + story_point_changes)*0.33

= (0 + 0.4893617021276596 + 0)*0.33 = 0.16148936170212494

​
​

Change in ticket xx-0003:

​
​

Changes in story points = (2 → 3) = abs(3-2)/2 = 0.5

Total changes in xx-0003 = (summary_changes + acceptance_criteria_changes + story_point_changes)*0.25

= (0 + 0 + 0 + 0.5)*0.33 = 0.165

​
​

Stability change in day 2 = ((Total changes in xx-0002*time_estimate + Total changes in xx-0003*time_estimate)

+ changes due to the addition of xx-0006(time_estimate)

/Total time estimate on the day 1)*100

= ((((0.161489*1200) + (0.165*1440)) + 720)/13440)*100

= 4.283%

Stability of the sprint on 2019-01-08 = 100 - 4.283

= 95.717%