Why I brought clothespins to work today?

That’s the question I was asked today when I came in to work; we’re trying a new format for redefining the team′s anchor stories, I answered. Here′s how that came to be.

Anchor stories are, in my opinion, another term for reference stories— both used commonly in the Netherlands. In this case, the team requested this event to define new anchor stories because they’ve had quite a few new team members who weren’t familiar with the old ‘faded’ anchors. They fell victim to ‘inflation of velocity’, this is a situation where a team is doing more and more valued work for the same complexity because they are estimating their Product Backlog Items (PBI’s) based on the time it takes them (and they can now simply do more in the same time).

A good anchor story helps promote effective poker-planning events, and, therefore, will help a team gain a better grasp on their predictability.

I imagine a PBI that has an anchor thrown out to be intangible to this inflation, which is why I prefer the term anchor story over reference story.

The goal of today’s event was to establish a new set of anchor stories so that the teams could give more consequent estimations (these are 2 teams that work on 1 product backlog and should therefore align their estimates thoroughly). I started with a short brainstorm on what, in their mind, characteristics of a good anchor stories are. This helped not only in aligning the expectations of the team members, but also to later recognize stories that didn’t fit these criteria and prevent endless discussions about specific PBI’s that had too much nuance and trap doors. Some PBI’s play out like a game of Snakes and Ladders and make great input for a retrospective, but they don’t make great anchor stories.

Now that we had a common understanding of a good anchor story, we looked at some of our PBI’s from the previous iterations. As a preparation for the event, I had selected about 20 PBI’s of various estimations, which I printed individually (I blurred out the original effort). We handed these out, giving every (pair of) team member(s) a few, to see if there were any PBI’s that would be useful. We then started by having the first team member briefly describe the PBI he or she felt was useful, trying to focus on the complexity in the description rather than the other specifics. He or she then hung the PBI on a clothesline with pins (which I, obviously, also brought in preparation- in our office this is not standard in a meeting room). The second person simply placed their PBI on the left or right side of the first. The following PBI’s all found their spot on the line as well. Every next PBI was briefly discussed and placed, resulting in a clothesline of increasing complexity, not yet labeled with a complexity-value.

The next step, after confirming with everybody that the order on the line was correct, was grouping the items in clusters of more or less the same complexity. Note that ‘only’ 12 out of the 20 PBI’s made the criteria of a good anchor story and ended up on the clothesline.    

As a last step for the day, we plotted our values (0,5-1-2-3-5-8-13-20, the team chose not to use the 40 and 100 values) on these clusters. Our clothesline was now a useful set of anchor stories, which we could use in a next poker planning event.

The final step, of what we decided to complete at a different time, is to deduct the characteristics of complexity per cluster. In other words, what is the common denominator that makes a 13 complexity a 13 complexity? This creates a more useful description of characteristics that are easy to recognize in future PBI’s.

Preparations:

• Select and print PBI’s of different value
• Some sort of line
• 20 or so clothespins

Schedule:

• Setting the goal of today, motivating and discussing the requirements of a good anchor story (10 min)
• Reading and separating useable PBI’s individually or in pairs (5 min)
• Describing PBI and motivating position on line together (25 min)
• Clustering the PBI’s on the line (if applicable) (5 min)
• Plotting the values on the clusters or individual PBI’s (10 min)
• Ending the session (5 min)

Total time would be 1 hour. It took me 75 min today, but that was due to the size of the team (10 developers / 2 teams). With a regular Scrum Team of 5 – 9 team members it should be possible to finish in an hour. The final step of deducting the characteristics can be done with a smaller group and presented back to the whole. I’ll let my team decide how to do this final step and if/how they want to capture the end result (poster on the wall or wallet sized laminated cheat-sheet). It needs to become their set of anchors.

What are your experiences in establishing anchor stories?