Measuring and defining risk with Cynefin

Measuring and defining risk with Cynefin

A common way of describing risk is using a likelihood vs impact metric. For example, there is a very low likelihood of an asteroid big enough to wipe out the earth actually doing so, however, the impact would be very high.

Many tools give you a lot of granularity when describing risk, one tool I used recently, called Kivue (which is a crock of shit), used integers. Likelihood = [1,2,3,4,5] (what is a likelihood 4, how is it different to a 3?). We used actual words and threw away two of the integers to make it more useful:


  • 1 – Unlikely,
  • 3 – Likely,
  • 5 – Definite

There were also integers for the impact, so we used actual descriptions for those instead:

  • 0 – No impact (why would this be important?)
  • 1 – Low Impact
  • 3 – Medium Impact
  • 5 – High Impact

Once you have your likelihood and impact, you can then work out your exposure:

Likelihood x Impact = Exposure

If you then rank your risks by exposure, with the highest at the top, this will give you a good idea of the risks you should be looking at first. However, having this still didn’t give us a real handle on how to assign a likelihood or impact to risk – one persons 3 might be a slightly more anxious and pessimistic persons 5!

I’d recently been reading (again, it seems to leak out of my head whenever I read about it) about Cynefin and it occurred to me that you can use it define risks. If you’re not sure what Cynefine is, this post may not be useful to you – you should start here and then here.  Basically, Cynefine is a decision making framework, where the problem spaces are known, unknown, complex and complicated. There’s a lot more two it than my pithy one-liner and I’d encourage you to take a look at the work of Liz Keogh to find out more.

Anyway, once you’ve up to speed…

Defining Risk


This risk is so obvious it might not even be a risk. We know the inputs and the outputs, it’s not complicated (as in, there are few moving parts and no dependencies) and it has two or fewer steps to complete the mitigation.

Impact: 1,3
Likelihood: 0, 1


  • Someone is on holiday. Someone else covers.
  • Hardware is needed. Hardware is bought.


This risk has more than two steps, but those steps are well known. The inputs and outputs are also well known. There may also be dependencies, these are also well now.

Impact: 0, 1, 3
Likelihood: Any


  • A team member doesn’t know how to use a technology. They need training from a peer.
  • Availability of a resource is unknowable. Seek alternate resource.


Multiple steps, multiple inputs and outputs, multiple dependencies. Some or all of which may be unknow. Work is required to move this kind of risk to “Complicated”. Although, this may not always be the case if we choose not to mitigate this risk, or there are simply too many unknowns.

Impact: 3,5
Likelihood: Any


  • A choice of technology is unconfirmed, work needs to happen to confirm the choice is appropriate.
  • Industry-wide definition of product format is changed.


Unknown steps, inputs and dependencies. More of a gut feel used as an early warning system. Chaotic risks should probably never be added to Kivue, although they could be added to a separate RAI register. A chaotic risk should be worked on until it can be move to complex or complicated.


  • Competitor is releasing a new, secret product.
  • Annual C-Level board meeting in which the entire company strategy is usually changed.

Impact: Any
Likelihood: Any


This worked for us and might work for you to. If not, then I’d implore you to come up with a common way of describing risk, it makes it easier to assess the relative “riskiness” of each risk and understand better where you should apply your mitigation efforts.

You may have other ideas on how to describe your risk impact and likelihood, and, if so, please comment below!

Butterfly Board

Butterfly Board

I was sent a product to review recently. This is the first time it has happened and I was delighted to oblige, as well, who doesn’t like free stuff? More importantly, it’s COOL free stuff.

The butterfly board is a whiteboard from the future. Now, you’ve probably either used, seen, heard of, or otherwise understand what a whiteboard is. If not, the internet is probably not a place you visit often. Either way, I’m not going to talk much about the whiteboard properties of a butterfly board as, well, they’re pretty self explanatory. But, if not, here is a picture of its whiteboard-y-ness.

This is not me, but it could be. It could also be you.

Whats this? A small, table-top whiteboard? What is this nonsense?

Oh, it’s more than that, it’s a portable whiteboard. WITH HINGES. MAGNETIC HINGES. Why has no-one thought of this before? You can make a whiteboard book, or simply make your whiteboard larger as it all snaps together. Did I mention the magnetic hinges?

Scalable (Snap Binding).jpg
Stick them together, make it massive. Have pretty nails.

Of course, the benefit of magnets is they not only stick to each other, they also stick to metal things, so you can smack the pages of your ButterflyBoard on a wall (or, another whiteboard, how meta). See:

Use case- brainstorming.jpg

This is so cool. Apart from the obviously fake marketing shot. “SCALABLE SUPER”

The pen is also pretty cool. It’s got an eraser on one end (which I never use, I just use the edge of my hand, then wipe my hand on my trousers like a five year old). It’s super thin, so you can make pretty pictures of butterflies.

You could also do other things with a thin pen.

Of course, you can use a regular sized whiteboard marker on it too. It writes just like a regular whiteboard, and smudges like one too. So, it’s handy that you can fold it up, one board of the ButterflyBoard can cover another, meaning that your beautiful butterfly picture won’t get ruined with it in your bag.

Talking of bags, it also comes in one. Which is good, as you don’t want to get marker all over the inside of your actual bag.

It’s sized just right – it’s like a large note book in terms of size, so plenty of writing space and not so big that it doesn’t fit in your bag or under your arm. It’s also light, but reasonably stiff, so you can write on it while it’s on your lap (just don’t get marker on your white trousers grandad).

If I hadn’t already been sent one, I would definitely have bought one, they fit nicely in your bag and so make a useful doodle/scratch pad and what self-respecting agile coach wouldn’t want a whiteboard with them at all times?

If you want to read more, watch videos or get yourself one, there’s an indiegogo thing running here:

Story Printer new features

Added some new features to the story printer and fixed a few styling bugs.

  • Added a ‘simple’ view to the site, this means you get to see everything in an easier fashion for editing etc. There’s still edit-in-place, it’s just easier than scrolling through the cards. You can still use the ‘card’ view, which you’ll need if you want to print the cards.
  • Tidied up some style issues with the card view, so it’s a bit neater now.
  • Added a newsletter signup, so you can be kept up to date with the things I’ve added.
  • A few bugs fixed.

Check it out at and please let me know if there are any new features you’d like to see.

Print your spreadsheet based User Stories

As I’ve mentioned in the past and spoken about at the London Scrum gathering, you should have a physical sprint backlog. The reasons are numerous; from being information radiators, to helping define a team culture. However, managing a large backlog of stories, especially if you have multiple backlogs for multiple projects, does become a challenge when trying to keep this information in a physical space.

Where I am right now, we manage our product backlogs using Google Docs. This works for us as it allows for flexibility when prioritising, we can move from room to room and, means we don’t have a large, messy surface of stories (although, I’m convinced this would help us – watch this space). One thing we do suffer from, is the transition of these stories stored digitally, to stories stored on a sprint backlog physically. Writing the stories by hand does mean there are sometimes further conversations around the stories, which is no bad thing, but it also means that often detail is missed from the cards, which causes problems later. This is due to the stories being written in a shortened form and, unfortunately often, a complete lack of acceptance criteria.

So, because of this, I put on my developers hat and created the Story Printer. This is a simple web-app, which allows you to upload a .CSV file and have it turned into printable story cards. At the moment, it’s very simple, but I’ve a few extra things on the roadmap which will add more useful features. But, for now, it does what it says on the tin.

Using the Story Printer, we now have a sprint backlog, with story cards that are identical to the stories in the backlog. Time will tell whether this prototype will prove useful.

Feel free to use it yourself and please contact me with new features, bugs or other stuff. I’d love to know if you use it, or would find it useful with additional features.

Screen grab of story printer
The Story Printer