‍Right Sizing Is Not the Same as Same Sizing

Every team I have ever coached has, at some point, has had a version of this same conversation…Someone on the team says something like, "we need to break this down so it fits in a sprint" or "this story is too big, it needs to be three points not a five." And everyone nods. Because that is how they were taught. Size the work. Force it to fit. Make everything comparable. The implicit assumption underneath that entire conversation is that consistency in size is what creates predictability. It does not.

Kanban teaches something different. It teaches right sizing. And right sizing and same sizing are not the same thing at all.

The Difference Between Right and Same

Same sizing is the practice of forcing work items into uniform buckets. Story points are the most familiar version of this. Teams assign points not to communicate how much effort something will take in any real sense, but to make items comparable so they can calculate velocity and fill a sprint. T-shirt sizing at the epic level does the same thing. You end up with a forced equivalence that feels like rigor but is actually just normalization.

Right sizing is something else entirely. It asks a different question. Instead of "how do we make this item fit our box," it asks "what does this item actually need to be in order to flow through our system well?" The goal is not uniformity. The goal is manageability. And those two things lead you in very different directions.

Right sizing is not about making all work the same size. It is about making each piece of work the right size for how it needs to move.

What Right Sizing Looks Like for Stories

At the story or work item level, right sizing means creating items that are small enough to complete within the expected timeframe your system is designed to support, but not so artificially decomposed that they lose meaning or create unnecessary handoffs. A right-sized story has a clear, valuable outcome. It can be started, worked on, and finished without requiring a dozen dependencies to resolve first. It moves independently.

The signal that a story is right-sized is not that it matches a point value or estimated number of days. Instead, the signal is that it fits within your team's Service Level Expectation. Your SLE is the empirically derived statement of how long most of your work items take to complete once they are started. If your SLE says 80% of items complete within six days or less, then a right-sized story is one that the team would expect to complete within six days or less. If a story is clearly going to blow past that, it is not right-sized. Not because it is worth "too many points," but because your system is telling you it is too large to flow well.

This is an important distinction. The sizing decision in Kanban is grounded in your actual system behavior, not in an abstract rubric someone wrote in a planning guide. Your SLE is the feedback mechanism. It is built from your own historical data and it reflects how your team actually works, not how a framework thinks teams should work.

What Right Sizing Looks Like for Epics

Right sizing at the epic level requires thinking about two things simultaneously: time and scope. An epic that is right-sized is one that can be completed within a meaningful time horizon but can also have an upper boundary in terms of count of child items.

That second part is where most teams fall apart. Epics grow. They start as a reasonably scoped initiative and then, over weeks and months, more items get added. New requirements surface. Adjacent ideas get attached. The epic becomes a catch-all container for anything that loosely fits the theme. By the time the team gets to the end, the original scope has doubled or tripled and no one quite knows how it happened.

A right-sized epic has an SLE of its own, defined at the portfolio or program level, that tells you how long epics typically take to move from commitment to completion, “75% of our Epics are completed in 75 days or less.” But it also has a right-size of child item count, for example “75% of our Epics are completed with 20 or less child items. 

An epic with an unlimited child item count is not a plan. It is a bucket with a Jira ID.

Same Sizing Creates the Illusion of Control

When teams same-size their work, they create a coherent-looking system that is actually hiding a significant amount of dysfunction. Here is what typically happens.

Teams spend enormous energy in refinement sessions not asking whether a story is right-sized for flow, but arguing about whether it is two days or three days of work. They are optimizing for scoping the work to fit the box rather than for the actual value delivery. The conversation is about the number, not the work.

At the epic level, same sizing through t-shirt sizing creates a false confidence in portfolio planning. Saying something is a "Large" tells you almost nothing about how long it will actually take, because a Large can absorb unlimited scope growth after the initial classification. There is no mechanism in a t-shirt size system that prevents an epic from quietly becoming twice as big as it was when you approved it. The size stays the same on the board. The work does not.

The deeper damage is what same sizing does to the team's relationship with their own data. When teams optimize for scope and size rather than cycle time, they lose the ability to make meaningful forecasts from real behavior. Velocity is a planning tool that tells you how many points a team moves in a sprint. It tells you almost nothing about whether specific work will be done by a specific date. Cycle time and SLE, grounded in actual completion patterns, give you something real to forecast from. Same sizing actively works against building that muscle.

How Right Sizing Enables Flow

Here is where the two ideas converge. Right sizing is not just a philosophical position about how to think about work. It is the foundational mechanism that makes flow predictable and sustainable at scale.

At the story level, using your SLE as the sizing constraint means that work entering your active workflow is work the system can actually process. You are not allowing large, uncertain items to sit in progress and age. You are not creating the condition where a single massive item blocks a column and inflates your cycle time metrics for every thing behind it. The SLE is both a design guide and a quality gate. If a story cannot be expected to complete within SLE, it should not enter the workflow in its current form.

At the epic level, right sizing works through two levers used together. The first is an epic-level SLE that gives you a time boundary. How long should an epic of this type take, based on historical data? If you are committing an epic to your portfolio board and your data says 85% of similar epics complete within 90 days, then you are making a time-bounded commitment, not an open-ended one.

The second lever is the child item count. When you commit an epic, you define the number of child stories it contains at that moment. That count becomes part of the definition of the epic. Not a floor, not an estimate. A constraint. If new requirements emerge mid-stream that would add child items to the epic, you have the ability to manage that scope growth as a deliberate decision with visible trade-offs.  New items might replace existing ones, the epic might be split into to smaller epics or the epic is re-evaluated against other portfolio priorities before work continues.

The child item count at commitment is not an estimate. It is a scope boundary. When it moves, that is a business decision, not a backlog grooming task.

Together, the SLE and the child item count create something that story points and t-shirt sizes never could: a boundary at the epic level that is tracked in both time AND scope. Flow is predictable when you can respond to this data in real time and when you can see whether you are on track to deliver. Right sizing is the mechanism that makes both of those things possible.

This is what Kanban is actually teaching when it asks you to right size your work. Not that everything should be the same. That everything should be appropriate. Appropriate for your system. Appropriate for your planning horizon. Appropriate for the way value actually needs to move through your organization.

‍