Friday 14 March 2014

Keeping the Kanban team fed

Running our Kanban Backlog

When we switched from Scrum to Kanban, one of the things we wanted to achieve alongside this was a better way of prioritising our backlog.  The previous product owner had used qualitative rather than quantitative assessments to select stories for the next sprint; we now had a new product owner, and he, with us, wanted to try and be a bit more analytical.

At this stage of our site's evolution, we were focussing on two metrics: engagement and commerce.  Engagement was measured by how frequently our user base logged in, and how long they stayed.  Commerce was measured by income generated.

We also wanted to provide some visibility of what was coming next for everyone, both in the dev team and the wider company.  Previous attempts to do this with a road map for the year had failed pretty miserably, so we didn't want to commit to "when", just "what's next".

Lastly, we wanted to a greater degree of engagement.  The value of previous stories had sometimes been questioned by the people building them, with a disconnect between the product owner and the dev team.  We wanted an obvious and visible way for everyone to be able to see the answer to the question "why are we doing this now?"

The Prioritization Meeting

We convened a fortnightly meeting, with people from various parts of the business, including at least one analyst, developer and tester from the dev team.  The meeting is chaired and facilitated by the product owner.

The output of the meeting is two lists of six features.  One list is the "Priority list", and is what we definitely want to do next; the second the "Reserve list" and is for features that we want, but didn't make the grade for the top division.

The One Pager

For each feature we create a form which we call a 'one-pager'.  As the name implies, it contains everything useful on one piece of paper:
  • A name
  • A very brief description
  • An impact rating (high, medium, low) on our two criteria (engagement & commerce)
  • A t-shirt size (small, medium, large) estimate on the effort
We allow anyone within the business to propose a new feature.  All they have to do is produce a one pager, and pitch it to the meeting.

How the Meeting Runs

At the first meeting we deliberately started with a blank sheet, even though we already had a backlog.  Much of this backlog was quite old now, and of questionable relevance.  The product owner and a few of his team produced one-pagers for the features that they felt they wanted, and then pitched them to the meeting.

We use a large graph on the wall with two axes - one measuring impact on engagement, the other on commercials.  For each feature a small post-it is stuck on the graph. A feature which the meeting thinks will deliver well against both measures would be placed top right; one which is poor on both would be bottom left.  The idea is for the meeting to reach consensus, but if it can't then the product owner adjudicates.



At the end we have a set of assessed features, and it is pretty easy to see which should be done next. So these are prioritised onto the two lists:


Note on Feature Size

The one-pager includes an assessment of 't-shirt size e.g. small, medium or large.  This is meant to be a very high level view, often taken after a chat with one of the developers.  We recognise that constantly working on large features is a recipe for indigestion, so the meeting also tries to maintain a variety of sizes in the features selected.  Ideally this should be another axis on the graph, but a 3D graph seemed to be overkill.  The rationale for variety in feature size is that the capacity of the dev team sometimes allows a small story to be fitted into the gaps between larger features.

Features and Stories

I've used the terms 'Feature' and 'Story' somewhat interchangeably, which is lazy of me.  We deliberately chose the word feature (or, more precisely, "Minimum Marketable Feature", which is the term used in much of the web literature) to differentiate it from 'stories', which we were familiar with from Scrum.  In our terms, a feature is a coherent piece of functionality which adds value to our business.  I describe a feature as "Something we would bother to tell our users about".
Typically a feature will comprise several stories, which is a more granular unit of work.  We try to stick to the INVEST model for stories, although as the stories all make up the feature, they are not truly independent.  When a feature is complete, that is when we release it.

2 comments: