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.

…and why we (temporarily) went back to Scrum

In my previous post I described the reasons why we’d moved from Scrum to Kanban.  This attracted a number of responses, ranging from “Yeah, that was our experience as well”  to “You’re doing Scrum wrong”.  Which is fine – the point of this blog is to write about my experiences and learn from others.

We've recently had a specific piece of work come up which we thought was ripe for trying with Scrum.  The simple headline of the project was "Re-brand the website to the new group brand".  There were a number of reasons we thought it worth using scrum again:

• The project had a pretty well defined scope
• The level of complexity was low, with few unknowns
• The deadline was relatively close (2~3 months)
• We wanted to try Scrum again, to test our thinking on our process

Creating the New Backlog

Working with the Product Owner, we produce a product backlog for the rebrand pretty quickly.  It had around 60 stories in it.  With a couple of people from the team, we quickly reviewed these, looking for the following:

·         Areas of complexity and /or technical risk

·         Logical dependencies (does it make sense to do Story A before Story B) [see below]

·         High level “T-shirt size” estimates

For around 60 stories, this was relatively easy to do.  We prioritised the stories that were complex, large or otherwise made sense to do sooner rather than later, and took them to sprint planning.

Story Dependencies

I should probably do an aside on story dependencies here, before someone jumps on me.  I know that stories are really meant to be independent and shippable alone or in any combination.  This is a worthwhile ideal, and something that we strive towards.  However, it’s just not always possible.  Particularly in this project - we wouldn’t ship, say, a rebranded header without the rest of the site being rebranded – in fact, the whole rebranded site will ship as a single release, tied in with other activity (customer communications, etc).   However, we have been releasing internally ‘work in progress’ versions of the site for other stakeholders to view and comment on.

However, that doesn’t get away from my general view on story dependencies. As I said, while independence is a worthwhile idea, sometimes it just makes more sense to do one story before another  e.g. story A might require some underlying software architecture or infrastructure work which other stories also need.

Sprint Planning for Sprint 1

I was nervous about our first sprint planning meeting, bearing in mind how terrible these were previously.  We took the prioritised backlog in, and starting discussing the stories.  While some of the old issues raised their heads, because of the relatively low level of technical risk and unknowns, people were able to generally agree on the points for each story without the endless discussions around implementation detail.  I think we got out of there in less than 2 hours, and with 7 stories worth 20 points for Sprint 1.  While this proposed velocity wouldn’t get the whole backlog done by the time we needed to ship the rebranded site, I wasn’t too worried as I knew that we’d front-loaded this sprint with the bigger and riskier stories.

What had we missed from Scrum?

Going back to Scrum definitely reminded us of some of the great things that we’d missed.  The short sprint deadline (we use 2 week sprints) definitely brings a degree of focus to the team that maybe we’d lost.   Sprint 1 went well, but in the process made me think about some of the things we liked from Kanban.

What did we miss from Kanban

As Sprint 1 progressed well, it looked like we’d over-estimated a couple of stories, and we wanted to pull some extra stories from the backlog.  Normally this is a no-no in Scrum, but from our previous Kanban experience, we weren’t worried about doing this.  We did set some basic rules – if a dev wanted to pick up a new story, they had to first check that there was no help (including testing) that they could offer on any existing stories in the sprint.  They also had to be confident that the new story could also be completed in the current sprint.

As the Project Progresses

We’re now at the end of sprint 3, and things are still going well.  Our decision to put the difficult/risky /technical stuff in the first two sprints has paid dividends, and the remaining work is getting simpler and simpler.  Sprint planning for Sprint 3 was particularly straightforward.

The constrained scope and low level of unknowns has meant that our analysts on the team are under-employed, however – most of the stories are so straightforward that a dev can often immediately start coding. It’s this lack of complexity which I think is key to our success on this project with Scrum.

What Next?

For the characteristics outlined above, Scrum works well for us.  Or, perhaps, it’s just easier to do. The stories are relatively homogenous, within a nicely constrained and defined scope, and with little analysis required.

Once we’ve delivered this rebrand, I expect to go back to Kanban.  I still think it works better when you have a range of heterogeneous stories, some with real complexity requiring analysis, and optionality on scope and release.

Why we moved from Scrum to Kanban

When I joined my current team, we were a full on Scrum shop: three roles (product owner, scrum master, team), three ceremonies (sprint planning, sprint review, retrospective), three artifacts (etc), the whole shebang.  And, it mostly worked, in that things got done, software got shipped.

However, in our retrospectives we had a few recurring issues that kept coming up:

• Our sprint planning meetings were horrible.  They went on forever (at least half a day), were exhausting, and everyone left them feeling like there must be a better way
• Testing was always getting squeezed towards the end of the sprint   
•  A reasonable proportion of stories (~30%) fell into the next sprint

When we delved into these, we developed some detailed explanations.

Sprint Planning Hell

The problem with our sprint planning meetings was that nobody wanted to commit to building the story until they understood how they would build it.  Consequently, each sprint planning became a design meeting, and often asked questions that the product owner couldn't answer, because at that point the story consisted of “As a user I want to A so that B”.
 

So we moved to asking the analysts on the team to develop a lightweight spec for the story before bringing it to Sprint Planning.

This resulted in the planning meeting becoming even more of a design session, which then often asked technical questions which couldn't be answered without some investigation.

So then we moved to having a ‘solution design’ session for each story before Sprint Planning, so that there was an approved technical design in place before we did planning poker on the story.

When was this analysis and design being done?  During the previous sprint, of course…

Squeezed Testing

You can’t test until there’s some code to test.  Of course, you can do test prep, you can write the acceptance criteria, you can set up test data, but… ultimately, if you’re a tester, you’re at the back end of the process.  And this is a problem, because any overrun by anyone ahead of you in the process affects you.  Was it ever thus.  

Consequently our testers were always under pressure – either they have to bust a gut to test the story before the end of the sprint, or they had to be the bad news bears and tell the Scrum Master (me) that the story wouldn't be ready and would have to be completed in the next sprint.

Stories Over-running

This issue is really a symptom of the previous two – with analysis and design being squeezed out of the front of the sprint, and testing out of the back, the sprint really just became the actual coding phase of the activity.  We even considered formally moving testing out of the sprint, but I drew the line at that one, and started looking for a better way.

Problems with Traditional Scrum

Based on the above, I thought Scrum had the following problems:

It assumes that everybody can do everything

I've never worked in a team like this.  At the very least, all the teams I've worked with have a split between analysts, developers and testers.  And within these, there will be people with specific skills – one story might need some serious database analysis, another some significant graphic design activity. Different people have different skills, and whatever process you use should recognise that.

It assumes that developing stories is a single task

Even within the (good) disciplines of a two week sprint, a story needs to go through a number of phases: 

• Elaborate
• Develop
• Test

Inside these can be multiple other steps (design, style, review, etc).  These steps are sequential – you can’t style the UI until it has been designed, you can’t test the story until the code has been written.

The combination of these two problems, that building software has different sequential steps and these steps are typically done by different people, led us to look at Kanban.

Why Kanban Works For Us

This article doesn't have the space to describe the history or background of Kanban – the web is awash with such articles, and I don’t think I have a great deal to add to them.

The key thing Kanban brought to our small team was the concept of flow.  That a story flowed through a sequence of steps, from “As a User I want to A so that B” to some shipped working software.  This flow has a sequence, and some dependencies.  Anyone who’s worked in a team building software for more than ten minutes knows this, so let’s recognise it and make it explicit.

Our First Kanban Board

As is traditional, we got a whiteboard, some markers, some post-its, and constructed our board.  It consisted of six columns:

Next	The next story to be pulled from the backlog
Elaborate	Add detail to the story so that it can be coded, together with a technical design
Develop	Write the code
Test	Test the code
Review	Business review the implementation, to make sure it meets the original idea
Closed	Released!

Each story flows across the columns, and, importantly, is pulled from left to right by the following step.  So, developers pull elaborated stories only when they've finished the story they've been coding; that story, in turn, is now ready to be pulled into test.

WIP Limits

A key feature of Kanban is its ‘work in progress’ (WIP) limits.  This is the way of defining when a stage in the process flow is at its limit, and no new work should be pulled.  In the early days, we didn’t impose these, wanting to see if any natural limits emerged.  In practice they did, and once everyone realised that the essence is only to pull new work when you have capacity, we had few problems, and didn't need to enforce WIP limits.

Advantages of Kanban

Having been running Kanban for over a year now, we've found the following advantages:

Visualisation

The state of play for the whole development team is immediately obvious to everyone in the office – including all the people who don’t work on the software delivery team. We used to have the Kanban board in the open part of the office, where everyone could see it.  We now have a big screen TV showing the virtual board in our ALM software, but that’s a whole different blog post.

Of course, every article out there on Kanban promotes visualisation as a key benefit, but I just wanted to add my voice to the crowd.

Continuous vs Batch

To me, Scrum often felt like a ‘batch process’ model of software development – you do these things, heave them over the wall (into production) and then do the next things.  Everything had to fit the two-week sprint cycle.  With Kanban, I feel like we're now using a continuous-flow process – small stories scurry across the board quickly, and can be shipped when ready; larger stories take longer.  I think it’s no accident that this is a good fit with the ‘continuous delivery’ model of software delivery.