Requirements are like bubbles

'Epic' is too good of a name for a piece of uncertainty that could fail you so badly!

I'm sure you've seen similar graphs before.

It's a release burn-up chart depicting approximation of done work to the planned scope. After three sprints the plan looks green: seems like the team will make it after the 5th sprint.

And then a KABOOM! New scope — updated projected release date.

Why does it happen? Many reasons: from scope creep to…

Wait a second, but what is scope creep exactly? Is "creeping" a kind of characteristic of "scope"? Can some scope be creeping more than some other? How likely is it in fact that a certain scope would creep, and at what pace?

We usually answer that we don't know. And some even would say that "we don't know what we don't know" (smart asses!).

But let me unpack this for you.

But how much do we really not know about what we don't know?

Let's imagine you need to implement payment mechanisms in your existing product. Some would call it an "epic".

I'll be calling it a "black hole". Because it can suck an infinite amount of effort and time. And no investments will ever go out of it. Don't go there.

A black hole.

Scary? Certainly should you be!

Let's look at some dynamics — evolution of black holes. As you guess, not everything that there is is what we know 0% about. Some things are clearer than others. Some can be refined at a faster pace. Some would remain black for some long time.

Here is a possible evolution of knowledge acquisition. That is what is happening within a product team that does its best to refine its upcoming work.

Now "payment" is not a disturbing point. But "other payment methods" is. PayPal is relatively straightforward to implement; Visa and MasterCard have more work and more uncertainty.

Bubbles bubbles everywhere!

In one recent product that I was consulting, we've started to apply this approach to all product features.

And we quickly realised that such a representation can help capture two essential dimensions:

1. Level of uncertainty / clarity
2. Relative size / complexity

So logically the size of bubbles is their relative size, and the colour — well, how clear they are.

If you're like us, you will end up using a simple tool (like Google Drawings) to capture and preserve requirements long-term. Having these diagrams widely accessible (at the corporate Google Drive) to everyone in the company allows you to infect people with the idea of bubbles — and it won't take long before you see the bubbles being drawn at any "product backlog refinement" session.

Let's add colours!

The size and uncertainty are two essential dimensions that allow you to have good deep discussions. But if you like complication then you'd go further (not necessarily that you have to).

We (complicated people) decided to add another dimension — readiness of implementation. The pro is that you can visualise not only how small/big and unclear/clear things are, but also how close they are to making money for the business. I guess that makes sense.

Refining requirements and separating knowns from unknowns is a good start, but being able to have a laser focus to deliver the clear pieces as fast as possible (to my view) is the next level of organisational maturity.

What's next?

I recommend you try this tool — bubble diagrams for requirement work.

And if you're like me (loves clear instructions), here's one for you:

1. Don't use JIRA or any other requirements tool during your product backlog refinement sessions (that's a really important step) — and if you have JIRA tickets, print them and bring them over to the session.
2. Invite people who have the knowledge of the upcoming work (subject-matter experts, users, user proxies) plus members of your development teams.
3. If you're too many — split into groups, otherwise stay together (but I really recommend splitting up).
4. Each group needs a whiteboard (flip-charts or big sheets of paper will do too, but whiteboards are much better here).
5. During a given time-box (say 15 to 30 minutes) each group focuses on one large piece of requirements (a product capability or a feature) and tries to break it visually apart by drawing a bubble diagram with two dimensions: uncertainty and size.
6. By bubbling the work, the team collects lists of open questions — they can be attached as leaves to the diagram too. Essentially the bubble diagram is an overcomplicated mind-map, so it is good for keeping associations.
7. Once the time-box is done, groups can either rotate (World Café style of facilitation), take new requirements to work on, or share their learnings with the whole group. Remember: product backlog refinement sessions are learning sessions, so your goal is to amplify group learning.
8. Once done, take photos and upload them to a wiki. Or update the Google Drawings to make sure the teams can continue referring to the bubble work where they have stopped today.

Critique? Questions? Comments? Please do.