In my previous posts about the definition of READY and Flow to Ready, Iterate to Done I have tried to shed some light on the Big Black Hole of Scrum: the Product Owner. This is number three in the series.

In my previous blog post I presented the stages that a backlog item flows through before it gets to Ready. But those were the ideas behind it: in this blog post I'll show how I've implemented them in practice. I'll show you two interesting examples.

The basic Ready Kanban has three columns: New, Preparing and Ready (see the explanation in the previous post of the series). You can add the fourth "In Sprint" if you want to show what's currently in the Sprint, but that's only really needed if it's not hanging close to the Scrum Board: otherwise the Scrum Board effectively functions as the In Sprint column. It's good to have a visual cue in the Preparing column to show the limit on work in progress, like a fixed number of slots for user story cards.

Rob's READY Kanban

This board was created by Rob Buster, one of the Product Owners at bol.com. As you can see his board has four columns since this board is hanging close to his desk, which is on a different floor from the team floor.

Some things to note on his board:

• he added a "Poker Ready" section, where he can collect a number of user stories that can be estimated in one go in a poker planning session. This is a very good idea and will probably end up on many Ready Kanbans. Even so, I specifically do not prescribe it in my generic format, since it's up to the work dynamic between a Team and a PO if they want to do this one at a time or in batches.
• the pink hearts were added by a colleague in the same room who found the large brown paper ugly...
• Rob uses blue stickies to partition his Ready buffer into Sprints. Again a very good idea, since it clearly shows the currently expected set of user stories to be picked up in the next sprint. It also allows physical shuffling of user stories to fill up the Sprints to the team's velocity.

The first Ready Kanban

This was the first Ready Kanban ever to be put up. I initially filled it with the top of the backlog that was in preparation: the top five in the "Preparing" state, and the next 10 in the "Top 10 New" state. Note that it's hanging in its logical place: on the left side of the Scrum board, in line with the overall left-to-right flow of user stories.

This is that same board a few days later (I've fudged out the titles):

Many interesting things had happened here:

• The analysts, who were performing all the getting-to-Ready work, started showing up frequently in the team room. Just like a Scrum board does for a team, it became their rallying point to discuss coordination, status and progress.
• The New buffer started drying up. With the improving speed of the team, many items on the old "change requests" list were reevaluated and found to be outdated or obsolete. It clearly pointed at a need to get the dialog with the business up to speed to get their requests. I had not expected this to happen, I thought that this buffer would always be full. It turns out that there is a subtle effect going on here: putting something in New implies a subtle promotion, and this leads to a simple triage being done on the user story. You could say that it functions as a "bullshit filter" .
• The top card in the Preparing column was stuck there while the ones below it moved. It became clear that there was an impediment in getting that user story ready, and extra effort and focus went into resolving the decisions to be made by the business.
• The Ready buffer was not filling rapidly enough. The level of the Ready buffer is a really good way to show if the velocity of the PO in sync with that of the Team. It works so well in this regard that the team members saw that it would not really be that useful to keep pounding away at functionality if the work would dry up. So they started to help the PO role to get user stories Ready. Now that is what I call self-organization!

Conclusion

All in all, I am REALLY happy with the results I've seen when I applied this board. All of a sudden the PO's have their information radiator, they can coordinate with others, stuck user stories are clearly visible, and now there is a basis for measuring the performance of the PO role. We can make a trend graph showing the level of the Ready Buffer (the PO's version of the burndown...), we can measure average completion time of a user story (in line with Lean's "takt time"), and the PO can bring some sanity back by limiting the work in progress in the Preparing state.

So please spread the word and make sure as many PO's as possible know about the Ready Kanban: the PO role is by far the hardest of all roles in Scrum, and I know from experience that all help is welcome...

What's up next? I hope I don't take as long as last time, but I'll show you how I implemented the Ready Kanban in JIRA. When you have a distributed PO role (or any distributed situation for that matter), you'll need support by tooling to bridge the gap...

Tags: Agile, product owner, Scrum
Filed under Agile, Scrum | 2 Comments »