The Changeability Decision Matrix
Responding to change over following a plan - The Agile Manifesto
That’s one of the four values to the Agile Manifesto. It’s also one of the values that is commonly plucked from the context of three other values and twelve principles. Once isolated, it’s exaggerated and inflated to some form of “We can’t define scope before we start work! There’s too much discovery work to be done first! We don’t know what we don’t know! Scope (and requirements) are emergent!” That bends the intent of the Manifesto and disregards the context from which a single value has been extracted.
I don’t believe Agile practices ever meant for software development to be a free-for-all, a never ending saga of finding and implementing better and better ways to code something before a product can be released. Projects run like this never see the light of day, let alone a shelf to languish on waiting for a long since departed market opportunity.
What isn’t in the Agile Manifesto, but is implicit in the Agile methodologies I’ve worked with is the notion of decision points. These are the points around which change, to a small or large degree, is not allowed. At least not for a while. Decision points bring stability to the development process from which Agile teams can move forward with a stable set of assumptions. If subsequent discoveries inform the team that they need to revisit a decision, than they must do so. The key element is that the work subsequent to the decision is what generates the need to revisit the decision. It isn’t done arbitrary, on a hunch, or with minimal information.
There are numerous decision points that exist within Scrum and SAFe, for example. Stories are decisions. “We need to create this thing.” Acceptance criteria, definitions of ready and done, sprint duration, feature and epic definitions, milestones, minimum viable/valuable products are also examples of decisions. Some of these can be quite changeable. Stories, for example, can be refined many times prior to and during sprint planning. The description, acceptance criteria, definition of done, and effort estimation can change many times before a story is committed to a sprint. And there’s the decision point. When the team agrees that a story can be brought into a sprint and they commit to completing it before the sprint is over, they have made a decision and the story shouldn’t change on its way to being completed by the team. (As noted previously, the work on the story may reveal a need to change something about the story – maybe even indicate that work on the story should stop – but that should be an edge case and not part of common practice.)
To help teams understand these distinctions, I’ve developed a 2X2 matrix called the Changeability Decision Matrix. Its purpose is to help teams evaluate the effects of changing work in the queue. The horizontal axis goes from “Small Impact” to “Big Impact.” The vertical axis goes from “Few Changes” to “Many Changes.”
The two questions the team needs to ask when thinking about changing a decision they’ve made (acceptance criteria, story description, MVP, etc.) are:
Will this change have a small or big impact? They may consider any number of variables: cost, time, productivity, effort, etc.
Will this change require a few or many changes (lines of code, documentation updates, other components that consume the code, budgets, release dates, etc.)
Where the proposed change resides on the grid may be dependent on where the team is on the project timeline. Consider the Epic, feature, and story hierarchy: Early in the project – during the design phase, for example – there may be little more than features in the backlog. As placeholders for ideas, they may be quite volatile as new marketing information enters the conversation or obvious technical issues become apparent. So changing an epic or a feature may have a relatively small impact on the project and involve few changes. Most probably there won’t be any code involved at this point.
As the project progress and backlog refinement continues, epics and features will be broken up into large stories. More detail is added to the backlog and more time and money has been invested in the design so the epics and features are less changeable. If any changes are needed, it is probably that the impact of those changes and the number of things that need to change will be greater than it would have been during the design phase.
Eventually, as the project moves into high gear, the backlog will become populated with more and more smaller stories that can be easily estimated and planned into sprints and increments.
For the duration of the project, it’s likely most of the stories in the backlog can and should be responsive to multiple changes…right up to the point the decision is made to drop the story into a sprint.
The Changeability Decision Matrix is an easy way to evaluate whether or not an Agile team is pondering undoing a small or large decision by forcing the conversation around the consequences of making the change. If either of these two axis are not a good fit for your organization or what you consider important to consider, then change them to something that makes more sense to your project.
Here is a representation of these phases on a hypothetical project timeline:
