Workbench Refinement

Product Backlog refinement is the act of adding detail, estimates, and order to items in the Product Backlog. – Scrum Guide, July 2013

Backlog refinement is very important to maximizing the amount of work not done by the Development Team. On my team, we recognize this and spend regular and focused time examining our Product Backlog with our Product Owner.

The Problem

It used to be that we sat around in a room, listening to the sound of the projector fan whirring and the temperature of the room increasing as each of us seemed the equivalent of a 500 watt heater.

The product owner would bring his laptop in and pull up Team Foundation Server, and we would walk through each User Story. One by one, we would fill out acceptance criteria, estimate effort, determine sequence, word-smith descriptions, etc. Sometimes, we would turn off the lights so we could see the projected image of his laptop screen. We squinted our eyes after every detail in the acceptance criteria and each nuance expressed in the notes until our vision blurred.

After about 30 minutes of that, we were all ready for a nap. It was too bad the meeting had been scheduled for a 3 hour block…right after lunch.
No one had to tell me that we needed a better way of doing backlog refinement, but in fact many did <span style=”font-family: Wingdings;”>J</span>. They mentioned the fatigue they felt keeping their focus for multiple hours. They kvetched about how hot it was in the room and how crummy they felt sitting and staring at a projected image. They bemoaned a feeling of being talked over by loud voices, never able to make their voice heard. They admitted being left behind taking notes in TFS as group conversation carried on without them.

The Solution

To address a couple of the key failings of our meeting structure, we decided that our meetings should have the following characteristics:

  • Be led by everyone, the quiet and the loud
  • Be short
  • Be effective
  • Be focused

We really liked the picture of a group of carpenters gathered ’round a workbench crafting a thing. Each would take a turn shaving away a bit of wood with the others watching and critiquing. In this way, each would shape the final product and each would share their wisdom and insight to validate assumptions and improve upon technique.

We liked this metaphor so much, we extended it backwards and forwards; these carpenters need raw material at hand and a place to store the final product.

The HOpper

The-Hopper

 

We call this first sketch the “Hopper.” In it, you’ll notice varying sizes of square’ish and circle’ish material. Those circles represent well-formed PBI’s. For us, that means a user story with a terse description and clearly stated acceptance criteria. A square may be littered with notes (usually acceptance criteria in disguise), complicated descriptions, or may even the lack of even those fundamental pieces.

Turning squares into circles seems to be best done by the Product Owner ahead of any Development Team refinement. As he orders the PBI’s by value, answers questions he knows the Development Team will have and struggles over wording and acceptance criteria, he carves off the corners and chips away away at the gross form until what remains can be easily taken in hand by the Development Team.

The Workbench

The-Workbench

 

Each developer takes a turn at the workbench, with the others watching and critiquing. They work through the description of the “who”, “what”, and “why” of the user story until they thoroughly understand it.

They sand down any remaining rough spots or slivers e.g. picturing the intended user, adding missed acceptance criteria, removing weak “so that” statements, estimate and re-estimate effort etc.Chisel and hammer in hand, they discuss it, take the scope of it in their hands, roll it around and feel all the edges.

The “Ready” Wall

Ready-Wall

There are many ways for a team to decide that a PBI is “Ready” to be taken into a sprint. Ultimately, shared experience will guide a teams’ gut better than some guy’s blog post advocating one set of criteria over another, so I will say only this:

Pay attention to why your team succeeds in delivering PBI’s and why they fail.

Construct an edifice describing your team’s collective wisdom to guide future refinement. Use this guideline as a barrier to casually calling a PBI “Ready” to be taken into the Sprint Backlog. Your team has spent scores of hours retrospecting and determining what worked and didn’t work regarding getting PBI’s “Done.” Consider defining “Ready” for your team based on their determinations so that they might be reminded of it before engaging the next PBI.

The Shelf

img-140731145049-0004

This is a section of the Product Backlog that is “Ready” to go into your next Sprint Backlog. As your team gets better at refining, you may be faced with to good┬áproblem of reigning in your time spent refining the backlog in favor of time spent developing the Product Increment. For reference, the Scrum Guide says that Product Backlog refinement:

…usually consumes no more than 10% of the capacity of the Development Team. – Scrum Guide July 2013

Product Owners need vacations too. Consider encouraging your Scrum Team to get enough PBI’s “Ready” to allow your Product Owner to, oh I don’t know, take a cruise for a Sprint.

How We Workbench

Our meetings are short. These days, we meet about once a week for an hour or so, but we used to meet more frequently and for a bit longer. Once our product owner saw that spending a little time making sure the user stories were well-formed allowed for much more efficient refinement, our meetings drastically shortened and felt much more relaxed while still being effective.

We like to merge our next 10-15 user stories into a Publisher template that displays the Description, Effort, and Sequence on the face of it. We take them up on left section of a 3 section wall. The left panel is the “Hopper”, the middle panel is the “Workbench” and the right panel is the “Shelf.” Each developer in turn stands, sharpie in hand, and talks through the aspects of the User Story described earlier. Any changes made are recorded on the paper.Once the team is confident it can complete the user story in the next sprint, we move it to the right wall section and mark it as “Ready.”

Once our goal is met, we determine who will take our printed user stories and record the changes in TFS. Usually, our Product Owner owns this task, yet it is perfectly fine that it be handled by any member of the Scrum Team. For reference, the Scrum Guide mentions that, although the Product Owner is the, “…┬ásole person responsible for managing the Product Backlog,” he may optionally have the development team do it, though he remains accountable.

The Workbench Works

Earlier I shared that the team wanted to refine our Product Backlog in a way that had the following characteristics:

  • Be led by everyone, the quiet and the loud
  • Be short
  • Be effective
  • Be focused

The workbench method as implemented by my team demonstrates these things.

  • Everyone has their turn to lead refinement
  • Meetings cost only 1-3 hours per Scrum Team Member per week (well under 10% time-box)
  • We produce highly refined user stories that have shown a high probability of getting done when included in a sprint.
  • Everyone in the refinement meeting has the opportunity to focus on the practice without external pulls.

Each printed user story now represents a delta; all changes and modifications are contained on a single sheet and can be reliably recalled at a later time. This frees the participants from capturing changes in real time and allows them to fully engage in the discussion.

We have had great success with this type of Product Backlog refinement and I encourage anyone who agrees with those 4 characteristics my team desired to consider giving it a try.

jknight

Jason is a developer, Scrum Master, writer, teacher, coach, husband, father, and community leader out of Tulsa Oklahoma. He's been delivering software since 2007 and absolutely loves the values and principles of agility especially as given form by the Scrum framework.