is a colleague of mine here in the Cary, NC area. He’s a Certified Scrum Trainer (CST) with the Scrum Alliance, which means he can teach certified Scrum Master and Product Owner classes.

With that title and role comes a responsibility to stay pure to the “rules” of Scrum and its defined practices.

So, Jason will often argue with me about specific agile practices such as:

• Sprint #0’s
• Hardening Sprints
• Release Trains & Planning

As (1) not being part of Core Scrum, and he’s certainly right about that, and (2) just being plane old bad practices. It’s here that I sometimes push back a bit on Jason, thinking that he might be a bit too purist in his approach and thinking.

But it’s all done in good humor and with respect.  Or at least I think it is. But that’s beside the point.

Getting to the Point

Jason and I sat down for coffee the other day to catch-up. You see we only live about 2 miles apart, but we rarely see each other in town. Normally we see each other “on the road” at conferences and other events.

One of the first things Jason said to me was:

Tell me about Backlog Refinement Bob. What are you coaching and teaching in this area these days?

I felt there was a backstory to his inquiry so I asked. Indeed, there was one. It seemed he was teaching a CSM class at one of my clients. And someone in the class said:

Bob said that we should only be spending 5-minutes per story on backlog refinement. To do more than that is a waste of time.

The emphasis here was on the “Bob said”. And Jason said that this comment was in direct contrast to a point he was teaching around immersive conversations as part of backlog refinement.

He mentioned that instead of “throwing me under the bus” in the class, that he wanted to find out what I’d actually said.

While I believe his intentions were from a position of information gathering, I had the distinct feeling that my agile competency was being tested or interrogated. It also felt like Jason was the “all-knowing CST” of Scrum and that he wanted to make sure that I was sharing the “right” information.

I spent the next 15-20 minutes explaining what I typically say around this topic in my classes. I don’t think Jason approved or disapproved afterwards, so I’m not sure where I stand on the Scrum Correctness Scale. Perhaps he’s simply digesting the conversation.

But what inspired me to publicly share the conversation is two-fold:

• I want to be transparent about what I perceive to be a slight dysfunction in our CST community. That is, judging what IS and IS NOT Scrum. While I get the need for this at a certification level, I want to encourage CST’s not to present themselves as the be all / end all judges on the topic. All of the agile methods are, after all, about being agile on principles and not getting too stuck on our tactics.
• But the real driver is that it reminded me that I haven’t shared some of my guidance and experience around backlog refinement. And that it might be worth taking some time to share. Particularly because this topic / activity is something so many Scrum teams struggle with.

Backlog Refinement

But the real driver for this article was to explore my coaching guidance around backlog refinement. It’s something I’ve been doing for 10+ years in my classes and/or coaching. But I thought articulating some of the advice here might be useful to you.

I’ll take the form of “anti-pattern” and then a complimentary “tactic” or more in describing ways to improve your backlog refinement.

Anti-pattern: Too much discussion at one time

Too many teams discuss stories in too much detail in one meeting or session. I sometimes call this – death by a 1000 questions. Yes, we eventually need to understand the story in enough detail to build it. But we don’t need to understand “everything” before an estimate or even before committing to it within a sprint.

This is the anti-pattern that Jason and my student had discussed, with some of the following tactics…

Tactic: Egg timer

Set a timer for 5-minutes for each story in a backlog refinement session. Perhaps add an additional 3-minutes if the discussion is healthy. Otherwise, try to advance the understanding of the story and then move onto the next.

Tactic: Estimate often

I often find that teams discuss everything before making their first estimate. I’d rather do the opposite. Estimate often and let the estimate variance drive the discussions. Also, never hold the teams to a single, non-changeable estimate.

Tactic: Establish a refinement tempo or velocity

This is a variation of Egg Timer. I think teams ought to try and have a tempo for their backlog refinement meetings. And also be aware of their velocity. I’d much rather have teams “explore” 10 stories in a 1-hour meeting than 1-2 stories.

Anti-pattern: trying to completely refine a story in one meeting

I think it’s fine to try and completely refine (get them READY) a story in 1-meeting. It usually works for trivial or relatively straightforward functionality. But my experience is that more complex stories need time. Often I call it “cook time” and this anti-pattern is determined that refinement speed trumps thoughtfulness.

Tactic: Simply advance the story

I think it’s better to have a goal of “advancing the understanding” of a story in each refinement meeting rather than complete understanding. For example, planning for a User Story Spike is a wonderful way of advancing our understanding.

Tactic: Change the focus

One way to improve your refinement is to discuss a collection or theme or group of related stories together. Then there is a theme or backdrop to the stories, so you can revert from one story, to the backdrop, and then to another story. The point here is to relate the stories to their overall theme or WHY you’re developing them.

Tactic: Allow for “think time”

I’ve found that allowing the team to have “think time” between story discussions can be incredibly helpful. It allows each individual to consider complexity, design/ execution approach, risk, and dependencies. I also think the estimates are much more thoughtful after a bit of time has elapsed from a teams first exposure to a story.

Anti-pattern: Product Owner writes all stories; OR Anti-pattern: Product Owner “owns” the Backlog

There are effectively two personas to this anti-pattern. The Product Owner drives the first, in that they view their job as a story (requirement ask) dictator. Somewhere they’ve been told or interpreted the role as being a command-and-control one. The second is from the team’s perspective. The team feels that the Product Owner should deliver “perfectly defined & refined” stories to them before they’ll estimate and work on them.

Both of these views are wrong! While the role of Product Owner is central to creating a thoughtful backlog, everyone on the team needs to weigh-in during backlog refinement.

Tactic: It takes a village to “own” a backlog

I’ve always coached for the view where the Product Owner is the mayor of the village, but where the village (the team) owns the product backlog. That is – everyone is contributing to and is accountable for the quality and thoughtfulness of the backlog. In other words – it’s a shared responsibility.

Tactic: User Story writing workshop

One way to assure the “village” mindset is to use user story brainstorming workshops as a means of writing stories. This is a session where the entire team gets together. The Product Owner “sets the stage”, for example: new feature, new product, next release, major epic deconstruction, etc. Then everyone chips in and writes ALL of the stories required for it.

Tactic: Release Planning

An in-depth and more focused session than the story-writing workshop, but with the same intent, is release-level planning. SAFe calls it Product Increment (PI) planning. Again, it’s a whole-team event where writing AND planning come together for a given releases’ set of features THEN stories. Also, so below for more context…

Anti-pattern: Writing too much; OR Anti-pattern: Writing too little

Two sides of a similar coin, as I find very few teams approach story writing in a “just right” level of detail fashion. And you would think that most write too little, but my experience is that its about 50/50. If I were to recommend “leanage”, I would rather have too little than too much. Why? Because it would drive more conversation…

Tactic: Iterate on each story

If you iterate, refining 2-3-4+ times per story, you’ll inevitably build-out the story to a just-enough level to define your level of understanding. Another approach is to only write things as the team ask for / needs information. So build a very rudimentary story and then enhance it iteratively.

Tactic: Keep notes

It’s not good enough to “collaborate” around the story. If you’re like me, you forget important details. I usually ask a team member to keep notes (right in the story tool) as we discuss each story in backlog refinement.  I don’t want every conversation scribed; just the important bits, decisions, and discussion paths. And rotate the responsibility so that everyone gets a “turn” at listening and writing.

Tactic: Write CRAPPY stories

As a Product Owner, often our inclination is to write the “perfect” story and “present” it to the team for approval. Often we get little conversation, because it’s perfect. I’d rather you deliver a “crappy” story to the team, one that barely conveys the intent for the feature. THEN encourage the team to fill in the details with you.

Tactic: 3-Amigos

The 3-Amigos is a model that encourages three personas to collaborate around user story development, that is (developer, tester, product owner). Most of the major refinement discussions involve these personas, which gives the story more nuance because of the different perspectives.

More info here:

Tactic: Vary the amount of writing

Every story should reflect the amount of definition the team needs in order to (1) understand, (2) implement, (3) test, and (4) deliver/deploy the story, but no more. Given that each story is then unique, the scope of each should vary. So try to avoid templates and boilerplates here.

Anti-pattern: Viewing stories as individual elements

When we were implementing software via requirements, it was all too easy to focus on the individual requirements, but miss the big picture. That’s why architecture and modeling were so helpful. Well if it can happen in waterfall, it’s 10x easier in agile to take a myopic view of the backlog; that is as simply a series of individual stories.

Tactic: Anchor stories

You see you have the choice as to how small (finely grained) you make your stories in the refinement process. Some like all of them small. I prefer a mix. Not only that, I prefer that each sprint contain what I would call an “anchor story”. An anchor stories are large, while still fitting into sprint length. They align with the sprints goal and are central to the demo. In a word, they are “lead character” in each sprint’s episode.

More info here:

Tactic: Themes, Sprint goals

I can’t tell you how lazy I find most folks when it comes to defining sprint goals or themes in general. I guess the view is that their “fluff” and not required. I find them the reverse – that is the most important thing you can define and then focus on. They encourage the team to understand the bigger picture – beyond the individual stories. And they give you something to focus your delivery towards.

Tool: Release Planning, Connecting the Dots

Many agile coaches and teams equate release planning to traditional waterfall planning. I’m not one of them. I think it’s one of the most useful things you can do as a Product Owner with your team. It gets the team to consider a “series” of sprints – leading towards a goal-driven release. It shakes out dependencies, risk, and workflow strategy. It also helps you understand what is indeed feasible in a fixed time frame. But beyond all of that, it creates a shared vision for the teams’ journey, which is priceless.

More info here:

Tactic: Maintain hierarchy

Stories usually start at an Epic level and then are decomposed into Features, Themes, and executable Stories. Often the history or lineage is lost as folks keep writing the stories. I think valuable information can be lost as well. I suggest keeping links to your story hierarchy as you build it out. Think of it as a storymap for your applications development. And child stories should inherit information from the parents – so that you don’t need to replicate information.

Wrapping Up

There!

I think I captured most if not all of my backlog refinement advice in the above tactics. Now I’ll have to run it by Jason to see if it passes muster.

Oh and there’s an important point I’ve been remiss in making.

Backlog refinement is NOT one of the Core Scrum events. However, it is mentioned in the 2013 Scrum Guide. Here’s the guidance:

Product Backlog refinement is the act of adding detail, estimates, and order to items in the Product Backlog. This is an ongoing process in which the Product Owner and the Development Team collaborate on the details of Product Backlog items. During Product Backlog refinement, items are reviewed and revised. The Scrum Team decides how and when refinement is done. Refinement usually consumes no more than 10% of the capacity of the Development Team. However, Product Backlog items can be updated at any time by the Product Owner or at the Product Owner’s discretion.

Higher ordered Product Backlog items are usually clearer and more detailed than lower ordered ones. More precise estimates are made based on the greater clarity and increased detail; the lower the order, the less detail. Product Backlog items that will occupy the Development Team for the upcoming Sprint are refined so that any one item can reasonably be “Done” within the Sprint time-box. Product Backlog items that can be “Done” by the Development Team within one Sprint are deemed “Ready” for selection in a Sprint Planning. Product Backlog items usually acquire this degree of transparency through the above described refining activities.

The Development Team is responsible for all estimates. The Product Owner may influence the Development Team by helping it understand and select trade-offs, but the people who will perform the work make the final estimate.

Hopefully this aligns to some degree with my guidance. Now if I can only get Jason to give me a “thumbs up”…

Stay agile my friends!

Bob.

BTW: I wrote another complimentary piece on this topic a year or more ago. I wrote this article without referencing it. You’ll see similarities and some differences between the two, but I still support all of the advice. I’d recommend reading it as well: