To me, much of Agile is extremely simple, but hard to master; harder yet if you do not know the why behind each concept. Relative sizing is one of those simple concepts. In this article, I will provide the “why?” behind relative sizing and provide insight into how to keep this foundational concept of Agile intact.
Why size our work?
Let’s start first with the question of “Why do we need to size our work?”. Sizing of anything is often viewed as an unnecessary evil, an overhead function. Why don’t we avoid sizing our work and just get busy doing our work?
The answer is simple. As an Agile Team member, we need to evaluate the work in our Team’s backlog. We want to ensure we are working on the high value items first. It’s hard to prioritize if we don’t know the relative size of the work in our backlog. We also need to forecast, to ensure we can provide the right value at the right time. It’s hard to forecast if you can’t equate work items in terms of the Agile Team’s throughput. Forecasting requires that we have some insight into the size of the work item, and the Agile Team’s pace in order to predict the duration as shown here.
Two other asks relative to sizing our work. One of the accountabilities of an Agile Team, perhaps the topmost, is to continuously inspect and adapt, to reflect and improve. So, we also want insight into how the Agile Team is improving. If they are improving, then their pace of providing value should increase.
Secondly, Agile requires a new mindset in contrast to traditional management. Often the distinction is shown in where confidence lives – in the people and their ability, rather than the process, stage gates and a detailed plan. So, as a result we should trust our Teams. We want to have complete transparency about the Team’s work, and we don’t want to have to re-interpret or pad estimates of the work, or micro-manage our Teams.
One final insight. Let’s face it... We don’t enjoy estimating, we know we are not good at it, and it has limited value. Using hours leads to micro-management and hides our sense of improving.
Even though we are not good estimators, studies show time and time again that we are great relative sizers. While I was working in Manhattan for a couple of clients I became aware of an interesting study being conducted by a local college. The study involved estimating the height of a dozen buildings in lower Manhattan.
Time and time again, groups of post-grad students were asked to estimate the height of buildings in feet and they were extremely wrong, in fact, some estimates indicated they thought the buildings were over a mile high. But when asked to do relative sizing they were extremely accurate. Finding the shortest building and calling it a “1” in height and determining the height of the remaining buildings relative to a “1” (a building roughly 3 times higher would be assigned a height of “3”) provided uncannily accurate answers and a quick consensus among the students.
I personally believe our ability to rapidly, accurately “size things up” in a relative sense comes from our survival instinct. To survive, when I meet a bear on my path, I need to rapidly size up the bear relative to me regarding speed, strength, agility and hostility in order to determine a safe course of action.
And guess what, at the end of the day all we need is a relative measure.
We need to prioritize the backlog of work, but we really just need to know what rises to the top. As we work on those items, we can flesh out and prioritize the remainder. Of the 30 work items in our backlog (either stories or features), we just need to know what is in the top third, and make our decision based on what is known at the time.
Principles
Relatively sizing your Team’s backlog of work comes down to 7 principles:
1. Each item is sized relative to the other items in the backlog. The easiest way to start is to identify a very small item, one that may take the team around one day to complete and labeling it as a “1”. All other items in the backlog are sized relative to this backlog item.
2. Each larger size represents increasing effort, complexity, and unknowns.
3. The size is the size to “get the item done, tested and accepted”
4. The Fibonacci sequence is useful since it provides an additive scale (something sized as a 3 is equivalent to the sum of something sized as a 2 and something sized as a 1), accounts for increased unknowns with increased size (since as our ability to even relatively size diminishes as work items get really large) and is fun to say. This is the mathematical sequence where each successive number is the sum of the previous two numbers.
5. Keep a reference list of example backlog items for each size, so that in the future all sizing is relative to the original list.
6. The sizing of the Team’s backlog of work is done by the Team, typically just the “Development Team” as defined by Sutherland in the Scrum Guide if you are using Scrum or the equivalent is you are using Kanban or a hybrid framework. These are the people tasked with delivering a potentially releasable Increment of “Done” product at the end of each Sprint. The Development Team consists of developers, configurators and testers. Surrounding this Development Team is the remainder of the Agile Team typically consisting of the Product Owner, Scrum Master and perhaps a Business Analyst or a Solution Architect.
7. Strive to have a backlog of “Playable” Stories at all times, that are defined and sized, enough for 3 Sprints.
Determining the Team’s Pace
Our pace is called “Velocity”. There are three principles behind the concept of velocity:
1. An Agile Team’s velocity is simply how many story points that Agile Team can complete within one Sprint.
2. Velocity is gained within the Sprint when a Story is validated to be “Done” based on the Team’s definition of “Done” and the Product Owner accepts the Story.
3. Velocity is predictive if the future Stories are consistently sized relative to past Stories. Don’t need to be accurate or precise, just consistent. A good way to be consistent is to keep a visible list of “reference” Stories for each size.
The concepts of relative sizing and pace are typically applied to Stories but can also be applied to other work items such as higher-level Features.
Anti-patterns
Anti-patterns are those ways of thinking that initially are sound and just, but later prove to have disastrous side effects. The following list provides a few examples that we have encountered along the way. Avoid these at all cost.
1. Premise - Others size for the Development Team or a subset of the Development Team sizes their work. Consequence - This action rips away at the autonomy of the Development Team, and typically results in inconsistent (and therefore worthless) sizing estimates. There are certain activities that are the accountability of the Development Team as a whole, sizing their own work is one of them.
2. Premise - We will have two sizes, one for Development and one for Testing. Consequence - This action further divides the Development Team into silos. According to Sutherland there are no sub-Teams in the Development Team. The point of the whole Development Team sizing together is to have those rich dialogues; this action reduces that potential. This action also complicates sizing and is a sure-fire way to slow sizing down without increased value.
3. Premise - Use fractions or non-Fibonacci numbers, typically since the Team believes the precise Story size is in between Fibonacci numbers, such as an 11. Consequence - Even with relative sizing we are not that good, but don’t worry, we will have large 3’s and small 5’s, everything will balance out. If we feel this Story is an 11, just call it a 13 since it is closer to 13 than to an 8. We do not need to be precise, just consistent.
4. Premise - Equate relative sizes to hours. Consequence - Although over time, relative sizes and hours to complete the work may be somewhat related, there is no linear relationship since size is influenced by three factors. You are not comparing horses to zebras; relative size points are unitless. Points are an indication of work item size, hours are used for duration and utilization. You are attempting to equate horses to kindling - they are two completely different measures. Equating sizes to hours opens the door to micromanagement, a de-motivating place where evil resides for Agile Teams. Focusing on hours is focusing on an easy to see proxy variable that is at best a terrible, distorted, unreliable reflection of value. Focusing the Team on hours will get you a highly utilized, busy team that is delivering no value resulting in frustrated customers, but you will gain confidence since the Team appears busy.
5. Premise - Tracking individual Team Member velocity, typically as a response to a perception that the Team Member is not pulling their weight. Consequence - Velocity is a Team attribute, tracking individually will completely obliterate the Team, motivating them to just care about themselves, not each other. The opposite of what we want in a Team. If there is a concern about an individual Team Member, the Team is most likely already very aware and probably waiting on you as their Manager to remedy the situation.
6. Premise - Size the entire backlog. Consequence - Once a backlog of work transitions from short names and descriptions to fully detailed and sized work items it becomes a queue. Although it provides Stakeholders false confidence, in fact long queues are extremely wasteful. Stagnant deep queues of idle work are the enemy of flow, increasing cycle time, delaying vital feedback and destroying process efficiency.
7. Premise - Unfinished stories at the end of a Sprint get partial credit and are re-sized. Consequence - Of course splitting Stories is a good practice, best done as part of ensuring the Story is “playable”, before the Story is picked up in a Sprint. Splitting Stories at the end of a Sprint, in order to get “partial credit” for the fine work the Team did feels like cheating, because it is. Aside from cheating the system, it is also a tremendous waste of time that undermines the basic core definition of velocity. Stories that “hangover” past the Sprint Close, should just carry over into the new Sprint. We need to be more concerned with continuous flow than with “clean” Sprints. A Sprint is just simply a timebox. A point to stop, reflect and adapt. Nothing more.
8. Premise - Comparing velocity across Teams. Consequence - Velocity is by definition unique to each Team. A better practice would be to compare relative acceleration as a percentage across Teams, if you indeed feel compelled to compare Teams. In my experience comparing Agile Teams feels like something we should do, but I have never seen any call to action as a result, just a good, ill-informed false confidence or a chance to demoralize the “slow” Team. Even in a Scaled Agile Framework setting, the use of “normalized velocity” is typically mis-understood and mis-used, with many participants forgetting that it is intended as just a way to get a new Agile Team to commit to a specific pace, when they have no real history to call upon.
Call to Action
So, the call to action is to keep relative sizing and velocity pristine. The best way is to understand the why behind these concepts, appreciate the underlying principles, and to avoid the anti-patterns at all cost. With this, your Agile Teams will be able to sustain a reliable flow of value and predictably forecast their work.