In this article, I would like to share about “Right-Sizing” the work for Agile Teams.
This technique can be used with Planning Poker and Extreme Quotation, however in this article I will also go further and demonstrate how it could be used with Flow Based Techniques.
There are references in the Flow Based Techniques parts of this article that are defined in the Kanban Guide for Scrum Teams created by Scrum.org, the landing page Scrum with Kanban is the home for this guide.
I recently received the following question from Michael Handley on the Agile for Humans community:
“Could you clarify or give more info on Right-Sizing?”
This article hopefully provides some insights around what I mean by “Right-Sizing”, and if you are really interested, how to use Flow to maybe bury “Story Points” forever.
Thank you Michael 
Constant Inspection and Adaptation follows the Cone of Uncertainty.
As time moves forward, our Doubts are replaced with Faith, then with Confidence, then with Conviction, and finally Certainty when it has happened.
From an Empirical lens, the future is never certain, only the past and present is the proof, the evidence to use for making decisions that guide to a future state.
When a piece of work is identified, it should be refined, at best the refinement of that work item should happen at the last responsible moment to mitigate risks incurred on an everchanging Product.
In Scrum, refinement is usually done on the work expected to be done in the next Sprint or two, in some circumstances, the team discusses urgent work or a new insight to see if it can dealt with before the end of the current Sprint without endangering the Sprint Goal.
A team should avoid wasting time to get Certainty
A team should seek to get Consensual Confidence effectively
Questions used often when sizing work are like “What is the size of this work item?” or “How big is this work item?”
These are valid questions for estimating work, they however can lead to long discussions.
Right-sizing involves a more effective question, “Is this work item too big?”
There are a few possible answers to this question, which should come in literally a few seconds:
“Yes it is”, “Could be” or “Maybe”
“Shouldn’t be”, “Should be ok” or “No it’s fine”
Saying “Too big” instead of just “Big” relates to what the team defines as “Big”. You could inverse the question and ask “Is this work item small enough?”
Depending on the responses of the team and the practices they use for estimating, the response should follow-up with simpler collaborative conversations for getting consensual confidence.
Consensual Confidence should be spontaneous, without delay, when people feel that it is not small enough, and the Scrum Value “Respect” is high in the team, they do not waste time comparing opinions, they accept the opinion of everyone and move on to deal with it to avoid risk.
If the team is not confident that it is “Small enough” then maybe it should be trimmed down (split) to make it smaller and achievable for the future Sprint.
With Cycle Times being tracked a team can define a Service Level Expectation.
Using a Service Level Expectation is one way of making transparent how the team works, the SLE is what the team is confident based on the historical Cycle Times.
Making Transparent the team’s Service Level Expectation to all will foster the same language both with Stakeholders and with the Team.
A team working with Flow Based Techniques should look at ways to improve their Cycle Times, they could even do this as early as the refinement.
The question used in in Flow Based Refinement is based on the question “too big or “small enough”, except different words could be used, “Is this work item bigger than our SLE?”
Is this question Transparent enough?
Maybe not, maybe we need a question that has very high Transparency and highly inclusive of the whole team.
How Big?
How confident is the team that this work item can be completed in less than X days?
Using a number of days as a clear boundary, the team will be looking for some form of consensual confidence around the work item for it to be ready to start on.
If the team is not confident, then the work item can be further refined and/or split with the usual Splitting techniques.
I believe a team could improve even further than just using their SLE.
What could happen if the team really strives for improvement?
One way could be to use a lower Percentile when refining.
For example if 85% of the work is done in 8 days or less, and this is the SLE, obviously 50% of the work is done in less time, let’s say in 5 days or less, the team could use that 50% Percentile when sizing the work and calling it ambitiously the “Target Service Level Expectation” or just simply the “Refinement Sizing Level”.
The answer to my previous question would be that the team could drastically improve their Cycle Times over a shorter period through constant Inspection and Adaptation.
Once the flow metrics are made Transparent, based on these measurements while the work item is In Progress, constant Inspection and Adaptation may happen, for example every day at the Daily Scrum.
With historical Cycle Times, Percentiles and the SLE fixed by the Scrum Team, we know when risk is increasing.
Let me give an example of how to use Percentiles for example at Daily Scrum to make Risk Transparent, and more importantly to enable the team to quickly Inspect and Adapt.
For demonstration purposes, let’s say the team has set it’s SLE at 85%.
Knowing the 50%, 75%, 85% Percentiles, the team also knows that 50% of the work completes in X days or less. If the current work item is not finished in this time, that means this work item is in the “upper 50%” of the work items previously done.
Before the work was started, there was a 15% chance that the work would be too big, representing the upper 15% above their SLE at 85%.
Here is the formula:
Risk = (100 – SLE) / (100 – Percentile)
= 15/100
= 15%
Percentile represents the current state of the work, not started is 0, finished is 100, and unfinished will cross Percentiles being used by the team for constant Inspection and Adaptation.
If the work item has taken longer than 50% of previous work items, let’s calculate:
(100 – 85) / (100 – 50)
= 15/50
= 30%
The work item now has a 30% chance it will not finish within the SLE, maybe the team should make transparent the reality of what is ahead and then decide if it is necessary to mitigate that risk immediately after the Daily Scrum.
Identifying the Uncertainty and the Risk associated, powering Transparency, empowers the Scrum Team to constantly Inspect and Adapt.
Maybe some choices that the team may make to avoid going past the SLE are:
Pairing – 1 extra person Mobbing – a few extra people Swarming – the whole hive
Using Kanban with Scrum will help a team to maybe bury Story Points forever and especially in some cases the time it wastes, for me that starts with “Right-Sizing” as early as the Refining of work.
If anything as an alternative to Story Points, Confidence will grow, and embracing Uncertainty may start.
Hope you enjoyed reading this article as much as I enjoyed writing it, any feedback is warmly welcomed.
by Elementor Pro
