As a follow-up to my post on estimating complexity, I wanted to share one of the interesting things I’ve been doing with the ideas and the numbers. This is quite long, but it’s turned out to be faintly revolutionary, and as far as I can tell it works, for the few clients I’ve done this with. It’s also based on ideas that are tried-and-tested by more than just me. Please do share any experiences that you get as a result of this, and especially places where it fails!

The Problem

One of the things that always bugged me about Scrum and similar processes is the idea that we start with a backlog, seemingly full-fledged from thin air. Sometimes the backlog has been drawn from an initial vision and is focused and prioritized appropriately, but more often I find that it’s been created using a “bucket” of requirements, and the bucket has come about because of old, Waterfall habits. When a business department know that they will only get one chance to sign up for what they need, they tend to create options for themselves (because options have value) by signing up for what they might need, and this habit has persisted. They don’t realize that because we now keep our codebase self-documenting and easy to change (which we do, right?) they still have those options, even when the first release is small.

Over the years, the development teams have fought against this tendency in both business and in themselves (YAGNI!), but I’ve still seen plenty of teams with over a year’s worth of fine-grained stories in their backlog, often with acceptance criteria sketched out. Sometimes those stories can take a week or two to put together, and I’ve sat in more than one multi-day release planning meeting.

I don’t like long meetings. I tend to fall asleep after an hour or so, even if my eyes are still open, and looking around the room I get the feeling that I’m not alone. So I’ve picked up my toolbox and gone looking for another way to do it.

It turns out that what I do is a bit similar to Gojko Adzic’s Impact Mapping. That’s not a surprise; both of us were inspired by Chris Matts’ Feature Injection ideas. Adding the complexity estimates (or, working out which things we know least about) is what makes the big difference, for me.

Let’s have a look at the process. As always, it’s a process that focuses on people and interaction, so it should be really lightweight. If you’re finding yourself bogged down by this, you’re probably focusing too much on the destination, and not enough on the journey. It’s OK to get just enough to start with, then start, and worry about the rest as you go.

Differentiators, Spoilers and Commodities

In “Domain Driven Design”, Eric Evans talks about the “core domain”; the thing that creates a company’s niche in a market. I came across the concept again in Waltzing with Bears, which starts Chapter 1 with the words, “If a project has no risks, don’t do it.” Dan North and David Anderson both used the words “differentiator”, and that was the one which rang best with me.

A differentiator is the thing which makes our company different to other, similar companies. It’s what makes this feature different to similar features. It’s the difference between doing it manually and having a computer help you. It’s being able to see a visualization instead of numbers; making it free instead of paid-for; making it expensive and exclusive instead of cheap and freely available. Identifying the differentiator for a project is the heart of this process.

The differentiator is at the heart of every thriving company, every useful product and project, and every successful person. Whether it’s Apple’s marketing strategy, or Wikipedia’s army of volunteers; the maintainability of that replacement system compared to the legacy, or writing the Game of Life using that language that you could never get your head around, doing things differently is important.

I like Niel Nickolaisen’s Purpose Based Alignment Model too, for helping us work out what to do when something can help us in the marketplace, but isn’t actually differentiating for us.

That’s relevant because when we see someone else’s differentiator, we might want it for ourselves, and vice-versa. We create spoilers from those differentiators. Kyocera made the world’s first cameraphone, and then Nokia popularised the idea. Nowadays that differentiator has been so spoilt, it’s commoditised; almost all phones have cameras in them, and often more than one.

The trouble is that when we ship a differentiator, we still have to ship all the commoditised, boring gubbins that comes with it. A phone still has to be able to make calls, receive calls and look up numbers; a cameraphone that doesn’t do that is… well, just a camera. So usually for every differentiating capability, there will be a number of commoditised capabilities that we need to ship too.

Drawing out Capabilities

Usually, every project has a primary or core stakeholder; a person or group of people who have fought for the idea, got hold of the budget or provided it themselves, and who have the primary interest in seeing their idea turned into something real.

(The primary stakeholder is the Product Owner. It doesn’t matter what title we give to other people; they can only be proxy POs at the most.)

In addition to the primary stakeholder, we also have secondary or incidental stakeholders whose goals need to be met to go live. (I have had people object to being called incidental, and others to being called secondary, so watch for people’s reaction to the language used here and find alternatives if you need them!)

We only need to meet the goals so that the secondary stakeholders will tolerate us going live (and Tom Gilb’s work on “Evo”, and putting numbers on these goals, helps a lot).

In order to deliver the goals – both the primary goal, and the secondary ones that need to be met – we deliver system capabilities. In a lot of cases these will be the same as the goals, but they may also be fairly low-level. These often map to what Agile teams call epics, though I’ve seen that word refer to everything from capabilities to features to stories that are just a bit too big for a sprint.

The capability is, quite simply, the capability for the business to do something, or assure something. For instance, we might have:

• The capability to comment on an article
• The capability to be on sale in the Apple Store
• The capability to make a copper trade
• The capability to prevent traders going over a counterparty limit
• The capability to stop bots spamming the site
• etc.

Some of these capabilities will be discrete in nature, and others will be cross-cutting, affecting multiple features related to other capabilities. We’re used to handling the discrete ones, and I’ll talk more about some ideas around cross-cutting capabilities in another post.

Sometimes people already have features in mind. If that happens, I encourage teams to help them “chunk up”, either by asking “Why?” or by asking, “What will that get for you (that you don’t already have)?” This helps people focus on the real goal, instead of worrying about the implementation.

If our capabilities could be met with enough people and bits of paper, or magical pixies that would run round and do the job, it’s probably phrased at the right level. If we’re including pieces of UI, or even looking at which devices it’s going to run on, we’ve dropped down to a feature instead of the capability.

Talking about features and breaking capabilities down into them can be useful for exploring those capabilities, and getting a good understanding of them, so it’s not a terrible practice. I encourage us to learn the difference, though. Knowing what capability is being achieved can help teams to think of other ways of achieving it, and those other ways may also end up being differentiating!

Uncertainty in Differentiators

We can easily see that when we create a new differentiator in a market, we have no guarantees that it will work. We don’t know quite what the outcome will be, or if we will find a working outcome at all.

Even when we’re spoiling someone else’s differentiator, we know that the outcome can be achieved, but we don’t usually know how to do it, or how hard it is. Perhaps the poor manager who took over that differentiating feature was fired for taking too long, and the company then shipped it anyway. Who knows?

These match the levels 5 and 4 on my complexity estimation scale. Once we get down to about a 3, it’s less of an issue; someone has done this before, and they work in our organisation, so we can go get the information. (Anything which has been done in open-source is usually a 3 at most, too, since we can get hold of the “how”.)

So, we now have all the tools to run a capability-based release planning session!

The Process

• Identify the primary stakeholder and the vision that’s going to be released.
• Identify any other stakeholders whose needs absolutely have to be met. If there are a few stakeholders that you miss out because you’re so used to meeting their needs, don’t worry too much about it. The important thing is to find the stakeholders who are most likely to stop us from going live.
• On big cards, write the capabilities that you will need to achieve in order to meet all the goals. These will usually be no more than a few words. You can chunk up with “Why”, and down with “Can you give me an example of that?”, or break things into features, in order to explore the capabilities. We may discover more as we do this! You won’t need to explore commoditised capabilities much (“the capability to register users”) but if you find anything differentiating, it will be worth having a conversation. I find 20 minutes to 1 hour per differentiating “thing” is enough (though you might start with more until you have practice), scaling down to 5 or 10 minutes for well-understood capabilities.
• If you’re not sure whether something is differentiating, you can ask, “Is there anything different about how we do this compared to normal? Or compared to how we did it in X project? Or compared to how Y does it?
• Estimate the amount of ignorance around each capability on a scale of 5 to 1, where 5 is “we know nothing” and 1 is “we know everything”. You can use the scale I mentioned in the previous blog post if you prefer; it’s much the same. You can also break off small parts of capabilities, if there’s only one part that’s differentiating – either as a smaller capability, or as a feature within it (but look for non-differentiating ways to achieve the same thing as they’ll be less risky, and if the feature is differentiating, look for the capability that it’s delivering).
• We should, by now, have at least one 5 or 4 in the capability backlog!
• If we have no 5’s or 4’s, we can ask what’s different about this project compared to other, similar projects. If we can’t find any, we’re probably better off partnering with someone who’s already done it, or getting it off the shelf, than doing it ourselves!
• If we have more than one 5 or 4, it’s possible that we’ve actually got a couple of different visions here. Is there a way to deliver one without the other? Would it be valuable?
• Once we’ve narrowed down what we need to do for the release, we have a Minimum Viable Product – either something valuable, or something that we’ll learn from quickly!
• We can even put estimates on the capabilities if you want. I recommend breaking them down only as far as features if you really want to do this, and using historical data about how long previous, similar features have taken, to estimate. I’ve also done this with story points made in 10s and 100s, just to show that there’s still lots of uncertainty around this. Don’t worry if you can’t get accurate estimates for the 4’s and 5’s, because…

Unlike the big backlog of requirements, there’s no point in delivering the most valuable thing first. We’ve already prioritised for value! We need everything in the release. If we don’t need everything, then we can make a smaller release!

So rather than prioritising for value in this backlog, we can prioritise for risk, and the risk will be the things we’re most ignorant about.

It will be the 4s and 5s.

As we take each capability, we can start breaking down the features and analyzing them, starting with the most risky of the features. There are some tricks here, too. You may not have to break down everything to start work.

Deliberate Discovery

A lot of Agile techniques are about predictability, and address the risk of integration, etc. by making vertical slices through the codebase, from end to end. That’s great when you know where the risk is! But for 4s and 5s, we often don’t know what we don’t know. There are tons of discoveries waiting to be made! So anything we can do to short-cut the process and make the discoveries earlier will help.

For instance, one of our early stories might involve a new piece of UI. The last time this happened, we hard-coded some data behind the UI and got it in front of users. It had been analyzed to death by UX experts, but I wanted to do this just because it was new. I didn’t worry about getting information from the database, because that wasn’t particularly risky. In this instance, the traders decided they didn’t like the UI! But it was very early in the project, so we had lots of time to come up with another one.

Another story involved the legacy system. We hard-coded a trade and made sure we had a way of getting that trade into the system, and that it looked much like the legacy system’s trades. We didn’t worry about using a real trade, or validation, or even session vs. request scope, because those were things that we understood (or had access to people who did), and which we could fix, later.

I wrote a post on how to split up stories back here. The important difference is that this time, we’re not focusing on whole slices. We might want to do that once we have validation, but until then, let’s just get some feedback.

Some concerns I’ve encountered

But I’ve already got a backlog!

Identify your main, championing stakeholder, and ask them to explain the vision to you.

Get hold of Gojko’s “Impact Mapping” book. Look at which capabilities your stories are delivering, and who the concerned stakeholders for each capability are.

If you’ve already got a backlog, chances are that there are no “technical stories” on there. You’re probably missing a few stakeholders, possibly ones who will stop you going live. Once you have the capability map, tout it around. Get it up somewhere visible. The other stakeholders will emerge.

If in doubt, try to get something live, early. There’s nothing like being wrong to find people who will tell you what “right” looks like!

We can’t make releases that small!

Get a copy of “The Phoenix Project”, and read it. The short answer is: you have just identified an organisational constraint. Find out if there’s a way of decoupling the deployment process, particularly, or if there are better ways of passing certifications. Remember that your target is not the process itself, but the end goal of that process.

I used to think that hardware manufacturers had a bit of an excuse. After all, you can’t update hardware that quickly, right? But then I saw what Joe Justice was doing with Wikispeed and cars, and how he was passing on those techniques to other manufacturers in different disciplines. I don’t have a huge amount of experience with hardware, but forgive me for being skeptical these days of excuses.

The PMO Office want us to do Scrum / Waterfall / something else!

The PMO office want to know that you’re addressing risk sensibly. The interactions I’ve had with people involved in governance over this process have been extremely positive (in one case leading the PMO member to sit with the team to see what they were doing!) If you’re worried about any particular person or group, treat them as an additional stakeholder. Bring them in, ask them what they need (and why), and include their concerns in the capability backlog.

This project is being done for political reasons, and this process is getting me into trouble!

Congratulations! You’re already a long way further than a lot of people. This means you’re awesome at your job, and will find another one easily. I will be happy to help, especially if you’re in the UK. Get in touch.

Can you help us do this?

Yes, if you’re in the EU or prepared to sponsor a visa. Please get in touch – liz at lunivore.com. I’m pretty good at fitting my work to budgets, and can even mentor remotely.

Enjoy, and let me know how this works for you!