Getting story sizes right is one of the most important skills of a successful team. Too much decomposition risks losing the narrative and getting side-tracked from a focus on the value stream, while too little decomposition leaves the work at risk of going in the wrong direction or getting blocked. The essence of decomposition is breaking things down to components of work that we can reason about.
If we’re going to leave effort estimation till the technical planning meeting, how do we measure the size of a story in the Queue Replenishment or Sprint Planning meeting? When we understand the various Methods of Measurement, then we know we have more tools in our kit than just time-based effort estimation. Nominal scales give us a way to measure specific qualities of stories. We can adopt a set of qualities as a screen for story decomposition, without having to resort to time-based effort estimations, which require more technical considerations that we have access to at this stage.
To be able to estimate for release planning, you have to come to grips with queue time. With story estimation, you have to work out the range of effort likely needed to implement the task, taking into consideration it’s dependencies. But effort estimation can’t tell you how much time the work will sit in state transitions waiting for attention. To understand queue time, you have to reason about a different set of problems.