Relative Sizing

“Story points are relative, without a connection to any specific unit of measure. The size (effort) of each story is estimated relative to the smallest story, which is assigned a size of ‘one.’ A modified Fibonacci sequence (1, 2, 3, 5, 8, 13, 20, 40, 100) is applied that reflects the inherent uncertainty in estimating, especially large numbers (e.g., 20, 40, 100)” — Scaled Agile. Inc.

Here is a guidance on Relative Sizing.

Aligned Starting Point (Starting Line):

One time only:

SAFe recommends that the first time a train is formed, that all teams utilize this: “find a small Story in your backlog that would take about a half-day to code and about a half-day to test and validate. Call it a “1” point. Then use this “1” point Story as the “Anchor” to Relatively Size the other stories in the backlog – vis-à-vis one or more of these four factors, C, V, K, U: 1) Complexity, 2) Volume, 3) how much is Known, 4) Uncertainty.

This helps teams to begin understanding and implementing Relative Sizing for Stories over time.

Again, this “Aligned Starting Point” is one-time only! This “One time only” activity is to “prime the pump” … and it is the start of the stream of actual historical data (real velocity (completed Stories over a span of time) for each team in the ART (Agile Release Train).

Don’t Look Back:

After bolting-out from this “Starting Line”, do not look back… meaning, forget the “about a day = 1 point” duration notion. After all, Story points are relative, without a connection to any specific unit of measure! So, unshackle your team from this duration notion. From here onwards, use Relative Sizing based on facts – Relatively Size Stories for future iterations vis-a-vis the Story sizes in the actual historical data (real velocity).

In other words, once the teams have actual historical data (real velocity), then they use their real velocity as the starting point for Relatively Sizing Stories for future iterations.

Create Knowledge. This is one of the Principles of Lean – Create Knowledge. The teams in the ART have just created knowledge of what “1” point is for them; each team’s “1” point is unique from the other teams’ due to the unique nature of each team. Hence we cannot compare a team to another vis-à-vis velocity.

Empiricism – Learn then Adjust for the next play! Each team will find, over time, that their version of a 1 point means something to them differently than what they have started with.

The point of this guidance on Relative Sizing is simply to have an Aligned Starting Point (Starting Line) for all teams in the ART.

Also, the Relative Sizing exercise is about Conversation and Mutual Understanding:

The point of this Relative Sizing exercise is also to have a Conversation and Mutual Understanding between the members of the Agile Team around the effort and complexity of a Story relative to other Stories in their backlog. It is NOT intended to ensure all things are perfectly defined into timeboxes within a day. I would suggest focusing mostly on the conversation around size relative to other items in the backlog and moving forward with the conversation.

Again, each team will find, over time, that their version of a 1 means something to them differently than what they have started with.

What If an item of work is very small?

If an item of work is very small as to be an hour of work total, it seems worth discovering a few things:

Is it a full item that produces value and it is not just a task?
Is it worth worrying about sizing it differently than one that takes half a day?
In theory, if you have a unique context where the normal nature of the work is predominately very small units of value that take much less than a day to complete, then perhaps a “1” in that setting is likely to be much smaller than in other more typical contexts where a team might need multiple days to complete a Story. In this case, make sure that that unique context is fully understood across the train.

You might have missed this:

The thing that many people miss in the SAFe guidance, is the reference to: “about a day = 1 point”. Two things to set this straight:

This “about a day = 1 point” is only used, one time only, at the Starting Line, when the team has no actual historical data … or they just want to re-start (they probably started off with wildly different approach to Story sizing across the train).

This “one time only” activity is to “prime the pump” … and it is the start of the stream of actual historical data (real velocity (completed Stories over a span of time) for each team in the ART.

Then forget about that “about a day = 1 point”! Put that in away – in a trash can!

From here onwards, use Relative Sizing based on facts – Relatively Size Stories for future iterations vis-a-vis the Story sizes in the actual historical data (real velocity).

It also helps ensure that the initial Relative Size of a Story is not wildly different across the train (i.e., some teams call their smallest Story as “2” points, some teams call their smallest Story as “1” point, etc. without any reason why).

Why bother with this Relative Sizing as the common approach to use by all the Teams on the ART?

Two benefits: Using this Relative Sizing as the common approach — with Aligned Starting Point — across all teams in the ART will:

1. Allow a sane “Capacity Planning” at the Program Level (ART). The teams in the ART bolted off from the same Starting Line — the Aligned Starting Point — and they used Relative Sizing as the common approach to Story sizing … not a chance of a case of “teams having wildly different approach to sizing across the train”. Wildly different approach to sizing across the train causes Capacity Planning insane if not impossible.
2. Make the ART’s Cost Per Story Point (CPSP) useable, meaningful, dependable, and solid as a rock – no variations on the approach as to how Stories were sized. Meaning, all teams are using Relative Sizing as the common approach … and all teams in the ART bolted off from the same Starting Line.

Management wants to know how many hours spent on a Story:

What if management wants to know how many hours is spent on a Story? How is this hour “derived” since Story is without a connection to any specific unit of measure)?

Answer: Create tasks below each Story and attached hours to each task.

Tasking is okay for this reason (to know how many hours is spent (estimated and actual) on a Story) and for the following reasons: