Using the Stacey matrix to capture agile metrics

Question

I recently encountered the Stacey matrix in an answer by Stephan Weinhold. After looking at the linked image provided & doing a bit more reading that describes it as a way to characterize complexity, I thought of two specific use cases for agile software projects.

Case 1. Definition of ready & backlog grooming

Part of my definition of ready is "defined well enough to be scoped." A story with too much uncertainty, vagueness, or disagreement isn't ready because it is then unlikely to be successfully completed within a sprint.

Thus if we plot our backlog on a Stacey chart, we could use a defined area in the lower leftish as part of the definition of ready. (EDITED to clarify: I'm thinking of a region roughtly the size of the entire lower left quadrant here, not just the lower left corner. I imagine the boundary would be wide, and might well be asymmetric.)

Furthermore, a story's location outside this area indicates what kind of grooming needs to be done in order to get it into the ready state. Items that are vague or not agreed as to "what" require mostly stakeholder work to get more clarity or agreement. Items that are uncertain or not agreed as to "how" could benefit from more research or an exploratory spike.

Case 2. Complexity metric in place of story points

The best practice for story points, t shirt sizes, or similar relies on having a standard unit story so your team can do relative sizing. But that can be difficult for various reasons.

Since story points have also been described as a measure of complexity, and the Stacey matrix is about measuring complexity, why not define a scalar based on Stacey coordinates instead?

It could be a simple sqrt(x2 + y2), or a less rectilinear version that gives more weight to the "how" uncertainty than the "what", which is what I'm leaning towards.

So my questions are:

A. Has anyone done anything like this? How has it worked?

B. What problems might arise from this approach, either for case 1 or case 2?

The one thing that concerns me about case 2 (using a Stacey metric instead of story points) is that, although it captures complexity, it doesn't capture size. I'm thinking maybe an INVESTed story is already within a reasonable size range, though?

EDITED TO UPDATE: I've concluded that size needs to be its own metric, and am working with my team to define an objective, similarly ten point scale. I plan to record the three scores separately, and will then play with various combinations to see which seems to be the most consistent across sprints.

Thanks for any comments, feedback, or further reading!

Vicki

Answer 1

I've seen this model used to drive these conversations in the past with a lot of success - especially if you are working with a team of people who like models. Like all models, this one helps us make sense of the reality we're seeing - it does not change that reality, so I'll take a minute to point out some pitfalls I've seen, but please don't let that discourage you from using this model - it is a good one.

Case 1 - Backlog Refinement

I've seen teams take this too far and decide that all items must be pushed to the lower-left in a simple state before they are ready. This can result in deadlock. Because a problem is complicated or complex does not mean it can't be done in a sprint. Further, some problems are unlikely to ever be moved from complex to complicated or complicated to simple - or it may not be beneficial to. In general, I see this being really helpful in backlog refinement in the same ways that you mention as long as the team doesn't get deadlocked.

As an example, let's say there is a problem with different solutions depending on the answer to a certain question by the users. I have two options here - do nothing until that question is answered or move forward assuming we'll get the question answered in the sprint. How big of a risk this is depends on how accessible the user is. I also have an assumption here that there is one answer. If different users give different answers, I will probably never leave the complicated realm and will simply have to implement it with multiple paths - waiting to get an answer in this case could result in deadlock.

Case 2 - Estimation

As you already point out, complexity is not size. It may be a component or influencer on size, but they are, in fact, two different things. My recommendation would be to start with noting the complexity before sizing as either the calculated number you mention or even a 2-part (3/6 would be 3 on the what and 6 on the how) and then use this as a factor in size. Maybe try it for a few weeks and then look back and decide:

1. is it useful?
2. is there a direct correlation between complexity and size for your team

I have worked with many teams where the answer to #2 is definitely no and they could not replace size with complexity, but depending on what work your team does, maybe they can. It's important to call out that this doesn't mean this has replaced story points as a size measurement - instead it would mean that you get more value out of measuring complexity than size.

Cynefin Framework

I'd encourage you too to look at the Cynefin Framework. It is very similar but also a different angle - stressing more how problems move through these states than categorizing which one they are in at a moment. It may give you a broader perspective when you look back at the Stacey model. It also suggests how to approach problems that are in the complicated and complex domain without having to first move them to simple.