How To Prioritise - Part II

I recently posted an entry on my blog about how to prioritise quickly and intuitively.

I presented a 2d matrix with importance (business value) on one axis and difficulty (effort/complexity/cost/risk) on the other.

It's a simplistic approach, but then that's what I like about it. Simple beats complicated any day!

And I also like the fact it helps people like me to visualise priorities.


Anyway, Scott Selhurst from Tyner Blain has extended this concept brilliantly.

In summary, Scott's idea is to make this approach more quantitive, so the output is a physical order of priorities and not just a graph for visualisation purposes.

Plot the importance/business value axis using points, rather than just a position based on relativity. Score importance 1-10, or 1-100 if you want more granularity, whatever you prefer. Plot the difficulty/effort axis also using points. If you're estimating using complexity points or the Fibonacci index, for instance, use this.

As well as giving you the graph above, Scott then shows how you can calculate a value:effort ratio for all the things in your list of priorities. This ratio, being a number, allows you to put your priorities in order. And in an order to deliver the highest value fastest, rather than just highest value first.

To read Scott's article, see here: Prioritisation and Value Maximisation.

See also:
How to prioritise quickly and intuitively
10 Key Principles of Agile Software Development

read more

How To Share An Agile Development Team

Scrum, and other agile development methodologies, provide a framework for managing software development projects.

But all too often, methodologies focus on a project environment, where the team is focused predominantly on a shared goal. Where the team is largely dedicated to the project.

In reality, this is often not the case.

In reality, development teams are frequently required to develop and support multiple products. Multiple products with multiple product owners. And particularly in 'business as usual' ongoing development.

So how do you share an agile development team?

Operating as a resource pool is often not ideal. Everyone throws their requests over the wall. Those that shout loudest get the team's attention. Or maybe the bigger products get the team's attention, at the expense of smaller products that never get to the top of the list, and never will.

Splitting the team by product sounds great. But sometimes the team's too small for this approach to be practical. Or it leaves too many individal developers, causing problems with cover and you can't exactly collaborate with one developer per product!

So what can you do?

We have a similar situation in lots of our teams. Broadly speaking we are solving it like this:

• There is one Product Owner per product. The Product Owner maintains a separate Product Backlog for each product.
  


• The development team acts as one team.
  


• The Sprint Budget (number of man-hours available for a Sprint/iteration) is allocated to each product based on our recharges, e.g. 60%-20%-20%. If you don't recharge, you could agree this at a more senior level as a general rule of thumb. Each product has a known % of the budget for each Sprint.
  


• Use Cases/User Stories/features are broken down into Tasks and estimated by the development team during Sprint Planning.
  


• Each Product Owner can only include Tasks from their Product Backlog up to their allocated % of the Sprint Budget.
  

This approach means the development team can act as one team. There is knowledge sharing and cover when someone is off, because in this case the overall Sprint Budget is reduced but everyone still gets their usual % share of the available hours.

It also means team members don't have to juggle their time between products on a 0.x FTE basis, which is awkward at best and just plain impossible when the fractions are too small or odd numbers.

Instead the Tasks allocated in the Sprint are already appropriate to the Sprint Budget per product, meaning team members can focus on delivering the Tasks in the Sprint, not worrying about how to split their time.

See also:
10 Key Principles of Agile Software Development
10 Good Reasons to do Agile Development
Top 10 Agile Development web sites

read more

How To Prioritise Quickly And Intuitively

If you're in a situation where prioritisation is straightforward and you have a single decisive product owner, you probably need to read no further.

If, however, prioritisation is difficult in your situation - maybe because you have several products or product owners with conflicting priorities, or maybe because your requirements can be complex and benefits rather intangible - this is for you.

In this case, prioritisation can be difficult and priorities are not always immediately obvious.

This simple approach might help you to prioritise more quickly and intuitively...

Draw a 2 x 2 grid. Use the bottom axis as 'Difficulty'. Make the vertical axis 'Importance'.

'Difficulty' should represent all the negative aspects, such as time, cost, effort, risk, complexity, etc.

The 'Importance' axis should represent all the positive aspects, such as revenue, cost-savings, and (slightly counter-intuitively) the risk of not doing it.

Make the left corner of each axis 'Low' and the top and right of the axes 'High'. What's in between doesn't really matter. 'Difficulty' could be your complexity points if your using Fibonacci estimating or something similar. But it doesn't really matter. The important thing is simply one item's difficulty and importance relative to anothers.

Plot each of your items on the grid, making an intuitive judgement about whether it's harder or easier, more or less important, than the other items already plotted. Make sure they're plotted roughly in the right position, relative to each other.

Get the relevant product owners to decide on the vertical position. Get the technical team to decide on the horizontal position. This is best done in a workshop with all the relevant people together. It's also important that only those qualified to judge should influence the horizontal position!

It's a good idea to start with the things that are clearly the easiest, hardest, most and least important. Place these in the corners of the grid to provide a useful context for other, less obvious items.

Once you've got all your things on the grid, think about the four quadrants. Things in the top left are "No-Brainers". These things are clear priorities. Things in the bottom right are potentially for the bin, as these things are of the least value.

Things in the bottom left are quite straightforward to deliver but not the most important. Consider ways to make them more valuable, i.e. push them up on the grid. Could they be chargeable features (if appropriate)? Or if enhanced slightly would they be considered much more important? Of course you shouldn't do this artificially; it's counter-productive.

Typically things in the top right quadrant are more strategic developments. Although they're over to the right, if you never start them you'll certainly never deliver them. Consider ways to simplify these items. Consider breaking them up into multiple things, so bits can move left on the grid and the strategic changes delivered over time.

This might sound like a simplistic approach, but you might be surprised how many things you're already working on that are not in the top left of the grid. And how many things you might not be working on, that are.

See also:

How to prioritise (Part II)

read more