I’ve been a Mike Cohn groupie for as long as I can remember. Mike has written, what I consider to be, three of the seminal books on agile approaches for software development. I’ll leave it as an exercise for you to lookup the books, but he’s really been one of the leading voices on how to “do Scrum” and “do Agile” for an incredibly long time.
I took my CSPO class from Mike and Ken Schwaber, just so I could learn from two of the “masters” in my agile journey. And when anyone asks me for a recommendation of an instructor for a CSM or CSPO class, Mike is at the top of my list. I remember sending all of our potential ScrumMasters at iContact years ago to Mike’s CSM classes. My logic was, that if we were going to spend the money, we might as well go to the best.
Now that I’m looking at the start of this article, I’m almost embarrassed as to how much of a Mike Cohn groupie I am. But I digress…
Now it pains me deeply to disagree with something that Mike said. I almost feel like Noah arguing with God over the details in developing the ark. But I’ll do it anyway.
Here’s the text of a recent newsletter (April 7, 2015) that I received from Mike on Backlog Grooming or Refinement:
Product backlog refinement—sometimes called product backlog grooming in reference to keeping the backlog clean and orderly—is a meeting that is held near the end of one sprint to ensure the backlog is ready for the next sprint.
During a product backlog refinement meeting, the team and product owner discuss the top items on the product backlog. The team is given a chance to ask the questions that would normally arise during sprint planning:
What should we do if the user enters invalid data here?
Are all users allowed to access this part of the system?
What happens if…?
By asking these questions earlier, the product owner is given a chance to arrive at answers to any questions he or she may not be prepared to answer immediately.
If those questions were asked for the first time in sprint planning, and too many could not be answered, it might be unnecessary to put a high-priority product backlog item aside and not work on it during the sprint.
These questions do not need to be fully resolved in a backlog refinement meeting. Rather, the product owner needs only to address them just enough so that the team feels confident that the story can be adequately discussed during the coming planning meeting.
Backlog refinement in that sense is really a checkpoint rather than an effort to fully resolve issues.
I like to hold the product backlog refinement meetings three days before the end of the current sprint. This gives the product owner sufficient time to act on any issues that are identified. Some teams find that doing shorter meetings every week rather than once per sprint are more suited to their cadence, and that is, of course, fine.
Unlike other Scrum meetings, I do not think the product backlog refinement meeting requires the participation of the whole team.
If you think about a whole team meeting three days before the end of the sprint, there is likely to be someone who will be frantically busy—someone who, if forced to attend one more meeting, may have to work late to finish the work of the sprint.
I’d prefer to conduct the meeting without such team members. As long as the same team members don’t miss the meeting each sprint, I think it’s fine to conduct backlog refinement meetings with about half the team plus the product owner and ScrumMaster.
Two Key Points
I have two key points that I disagree with Mike’s perspective:
- I don’t believe that Backlog Refinement is simply a meeting tied to the current sprint and focused solely on the “next sprints” contents;
- I don’t believe that team members can “opt out” of participating in the meeting.
There is an “in the moment” nature to his recommendations – that is in the sprint. I believe that’s why the advice is myopic. That being said, I have an entirely different view towards backlog refinement. It includes what Mike recommends, but is so much more than that. Let me share.
Backlog Refinement
I view backlog refinement is a continuous exercise where the team gets together and views, discusses, hashes out, improves, estimates, breaks down or decomposes their backlog. It’s an ongoing activity for me that is requisite overhead for the team.
I usually recommend having regular meetings, most often twice a week for 1-hour each. The purpose of the meeting is always the same:
Advance the understanding, clarity, and sprint readiness of the stories on the Product Backlog
But the focus of the meeting can change. I often speak about three primary “lenses” that can be applied to the Backlog Refinement meeting.
Lens 1 – The Next Sprint: This is the lens that Mike is focusing on. The meeting augments sprint planning in that the team is examining and discussing the stories targeted for the very next sprint. These stories should be, by definition, READY for execution. And if the team determines that they’re not, then the focus is on clarification around their Definition of Ready or Readiness Criteria.
Lens 2 – Several Sprints in the future, or the current Release: This is the mid-term lens where we’re trying to anticipate future work and the implications to our current efforts. Quite often, if you’re using a release train model, the team is committed to a train and it’s contents. Thus the ongoing refinement helps the team in advanced understanding of the details and whether they need to make scope commitment course corrections.
Lens 3 – The Next Release, The Future: In Mike’s article, he focused on lens 1 with no mention of the other two. I can assume then that this is highest priority for him. I actually view lens 3 as the highest priority. This is the lens that is setting the stage for future release(s) and sprint(s). It’s the one that determines raw scope of epics and features and how they are best coupled together. It also exposes early discussions around architecture, UX, technical complexity, and design options. In fact, story spikes are surfaced and planned from the activity under this lens.
My typical guidance for backlog refinement is to switch the lenses as appropriate as you are “looking ahead” on your backlog. The discussions vary greatly under each lens. Typically lens one focuses on detailed understanding and sprint readiness. Len two discussions are a little more abstract, but the goal is to get the story stream ready for execution. And as I said, lens three is trying to connect the dots from the now to the later.
My biggest concern with Mike’s statements is that the team taking his advice will lose any connection to the future. This will impact the health of their designs and drive up rework. I’ve also often seen it impact morale because there is little/no sense of the “big picture”.
And what about team engagement?
I just attended a local agile conference here in the Raleigh/Durham area. It’s called TriAgile. One of the speakers, Arjay Hinek, is from Red Hat and he did a presentation on leveraging Backlog Refinement as a means of detecting and improving team agile practice health.
You can view the slides from the presentation here.
I thought Arjay did a nice job in the presentation and he examined refinement from a perspective that I’d never thought of. It was a really interesting talk.
But Arjay mentioned supporting Mike’s perspective during the talk – that backlog refinement needn’t include the entire team. In fact, he said that it could be effectively done with only a small sampling of the team. I mention this because of the influence that Mike has in the agile community and how I believe folks, sometimes quite experienced coaches, and are getting the wrong impression.
Read my Lips
Backlog Refinement is a whole team exercise. It is way more than simply talking about and estimating a few user stories. Way more! It is the ONE planning event for all levels of planning within agile teams.
From my perspective, it is doing the entire team a disservice to allow team members to opt in or opt out of the meeting. It is for everyone.
The best way I can amplify it is to point you to a recent post I did about agile being a “team sport”. Please read it and encourage your teams to attend their Backlog Refinement meetings and engage in the activity – if not for themselves, then for their TEAM.
Wrapping up
So as much as it pains me to say it, I think Mike is truly wrong with his shorter-term perspectives expressed in his newsletter. The real danger though is the influence that Mike has in the overall agile community. People listen to him and often (blindly) follow his advice.
Here’s what the Scrum Guide has to say about Backlog Refinement
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.
There are two “lenses” mentioned here, the pre-Sprint lens for execution readiness and the ongoing activity lens for continuous backlog understanding and refinement. The other implication is that it is a team-based activity and not an opt-in based activity.
In my experience, quality backlog refinement is a critical activity for high-performance teams. And remember – it’s a PLANNING activity.
I hope I’ve encouraged you to think a little differently about your backlog refinement. Now if I can only get Mike and Arjay to do the same…
Stay agile my friends,
Bob.