Qualitative Decomposition
taming complexity through the qualities of things
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.
Qualitative vs. Quantitative Estimation
Scrum practice specifies a set of attributes precisely for this purpose of qualitative assessment of stories in the planning stage which goes by the mnemonic “INVEST”: is the story Independent, Negotiable, Valuable, Estimable, Small and Testable? Let’s work through what we mean by each of those attributes, to see if they help us understand if we have the right level of decomposition.
Evaluating INVEST Attributes as Qualitative Estimation
The INVEST attributes are qualities of the work being evaluated which together constitute a sort of screen through which stories must pass to go into a work queue.
Independent
We want to make sure that our stores are not entangled with other work in ways that might unnecessarily complicate getting the work done. We’ll want to enumerate dependencies and to evaluate if any of those can reasonably be broken out separately. In the planning stage, we can delve into implementation, and explore how various approaches play out in terms of separation of concern and the prospect for the work to getting snarled up in related issues.
Negotiable
The quality of being negotiable indicates that the business objective of the story hasn’t been lost or pinned down in the technical specification. If we have work that everyone seems to understand and agree on value and viability of the story, but it is in the form of a statement of what to do, rather than what objective must be met, then we’ve lost negotiability. If unforeseen dependencies or technology issues emerge when it goes into work, then it is more likely to become blocked. Making sure that the statement of work is primarily a statement of what the business needs out of the effort leaves room for the development team to renegotiate the proposed implementation, so long as the desired outcome is met.
The principle of negotiability is essential to Scrum because the work is constrained to a non-negotiable time-box. If the development team can meet the essential goal within the Sprint, then that is generally a better outcome than rolling the work into the next sprint, so that a predetermined, specific implementation of the story can be delivered.
Valuable
The value of the story was already established in backlog refinement when the work was prioritized and promoted to the planning stage. Still, circumstances change. Developments in the business, deployment environment or technology may change the relative value of a story. We should ask this question at every gate, and to take the opportunity to drop any work what doesn’t pass the value test before it goes into work.
Estimable
It seems common for people to confuse the qualitative question: can we estimate it? with actually estimating the work in terms of effort — the very fact that we can answer yes to each of the INVEST attributes for a store is a form of estimation. At this stage, we just asking: is the amount of uncertainty you have about the story so great that it should be further refined before queuing it for work? The effort estimation, if you choose to do that, would happen as an outcome of technical planning, just before the story goes into work.
Small
Asking if a story is small is effectively an extension of asking if it’s estimable. We’ve already looked at the question of size in backlog refinement, and we’re not going to attempt the effort until technical planning, so we should still be on some ordinal scale evaluation.
Testable
Evaluating if a story is testable is simply a time to stop and consider if there is something particular about this story that is unique concerning verification. For most stories, testability is not a problem. Whether you do, it is another question, but here we’re just considering if we’d know how to approach it. If a story interacts with a 3rd party service, then it may not be clear how’d you’d verify that the interactions perform as expected; you might add a specification to build a mock of the service to test against, then you could induce failures on the service side that would hard to do otherwise.
Decomposition is tough work. It’s not merely a question of breaking work down to smaller chunks, but organizing how we approach the architecture, how we work together as a team and agreeing on how to structure out planning meetings. In theory, the time we spend getting to the right decomposition will be more than paid back in time saved in implementation and delivery.
Artiom Vallat — "Cockpit at Night"
Let's agree to define productivity in terms of throughput. We can debate the meaning of productivity in terms of additional measurements of the business value of delivered work, but as Eliyahu Goldratt pointed out in his critique of the Balanced Scorecard, there is a virtue in simplicity. Throughput doesn’t answer all our questions about business value, but it is a sufficient metric for the context of evaluating the relationship of practices with productivity.