Do Right Digital

A BCD Entity - 3D story pointing

The Problem

It can be difficult to decide between different options that seem similar. It's particularly difficult when making a group decision where some technical expertise is needed. This is often the case in technical projects large and small. BCD is intended to help the conversation and become a long-term representation of the information you used to make the decision.

What is a BCD Entity?

A BCD Entity contains 3 numbers between 1 and 21 from Fibonacci Sequence. The numbers represent:

  • Benefit: How useful this task is this feature ones it's completed?
  • Complexity: How complex/difficult is it to complete?
  • Danger: How likely it is to go wrong or break something?

These can be drawn in a triangle with Benefit at the top, Complexity on the bottom left and Danger on the bottom right. The centre of the triangle is in the middle of the bottom line.

An empty BCD Entity

Prioritising & Picking tasks

Once you've got the scores for each you can start to prioritise tasks and pick individual tasks purely based on the BCD of that task. A tall thin triangle is preferable to a tall fat triangle. A short fat triangle is a task that's probably not worth doing while a tall fat triangle is one that should be tackled early in an iteration as it's important and likely to cause problems.

If a task has a Danger Score of 2 and a Complexity Score of 13 then you know you'll need more dev resource compared to QA resource. If another task has a Danger Score of 13 and a Complexity Score of 2 then you know you'll need more QA resource than dev resource.

When you're working on these tasks it's good to have the visual reminder of the BCD because it might affect which task you start on a Friday afternoon or a Monday morning. Something that's important and dangerous might not be good if you can't give it your full attention.

When can a BCD Entity be used

There's no real limit to it but it's primarily designed for:

  • Planning tasks in a tech project
  • Triaging bugs
  • Discussions between technical experts and their clients

In an Agile Development team

Normally when we plan tasks we'll estimate with abstract measures of complexity. The are picked from Fibonacci's Sequence but they only describe one part of the information required to plan and prepare for the work to be completed. Each part of the BCD Entity is voted on by the whole team during planning sessions using the Planning Poker technique. Everyone gives their opinion but one person or group has the final say on each part:

  • Benefit: The Product Owner has the final say on the benefit. The developers might want to argue for a higher value if they see additional benefit but the PO/BO has final say. If you're torn between two numbers use the lower number.
  • Complexity: The developers have the final say on the complexity. Just like normal Planning Poker the whole team estimate complexity. If you're torn between two numbers use the higher number.
  • Danger: The QAs have the final say on the danger, in the absence of QAs the developers own this too. If the danger seems particularly high you may want to discuss different features which would satisfy the overarching business requirement. If you're torn between two numbers use the higher number.

What to expect

Most of your tasks should be roughly equilateral, any task that's not is a bit of an anomaly. The no brainers are represented by tall & thin or short & fat triangles. The tall thin ones are quick wins, the short fat ones are more hassle than they're worth.

The numbers available are a finite scale, this is intentional. If something's more than 21 benefit, complexity or danger it should become two tasks. If you find this limiting it may be that you've started your scale too high, don't be afraid to go back and re-point some old tasks.

Planning and Prioritising

Depending on your workflow you might want to use BCD in different ways. For example in Business As Usual workflows you want to consider the ratio between the height and width of the triangle approaching the tall thin ones before the short fat ones. If you've planned a sprint, iteration or MVP and you have a list of the highest priority (tallest) tasks that need to be completed you should approach them starting with the widest and leading to most narrow. Once you've completed your Must Have tasks and you're onto Nice To Have you can start picking off the narrowest Nice To Have tasks and work your way towards the biggest ones - this avoids dangerous or complex tasks being tackled at crunch time.

Over time we're hoping to provide some algorithms to sort your tasks into a draft order, it doesn't trump the product owner's decisions but it should help to sort the obvious ones that should be near the top and near the bottom.

How can I get started?

Why not start by printing up some BCD Index Cards and try it out at your next planning meeting. Why not keep some BCD Discussion Paper on your desk?