The Backlog Refinement Sweetspot


I published this almost two years in a separate blog. I just started with a new company, and I have been working with several folks who are not too familiar with Scrum and some of the finer details around the events. I’m republishing this article with a few edits here and there. I hope it helps some teams that might be struggling with their Refinement sessions.

Setting the Stage

If there’s one ceremony that is very susceptible to ‘going off the rails’, it is backlog refinement. The very nature of the meeting invites the temptation to dive into more detail than necessary. This is expected; as a former software engineer, my inquisitive nature often gets the best of me. Drawing the line between ‘valuable refinement discussion’ and ‘getting lost in the weeds’ is a common challenge. There are a number of techniques a team can use to refocus including: time boxing, strict facilitation, limiting non-essential participants, etc. A few months ago, my colleague introduced me to a teaching point that we felt would help our teams take control of their Backlog Refinement sessions. Rather than tell the team that they’re going into too much detail, we offered them a technique to help them self-diagnose. My preferred moment to coach this strategy is at the beginning of the refinement session. At the beginning of the session, I like to remind the team the true intent behind backlog refinement: ‘To acquire just enough information on a story to size, so that the Product Owner can clearly review and prioritize it compared to other backlog items’. The emphasis is strongly placed on ‘just enough’. Development Teams may insist that they have to cover all the details in refinement; remind them that the implementation details should be left for Sprint Planning or story kickoff sessions. The Scrum Master should do his/her best Aaron Rogers impression (sans mustache):

After setting the tone for the session, the graph below is introduced. It represents the qualitative journey a team takes when discussing stories:

Graph Walkthrough

Approaching Point A (Brand New Story)

As a team discusses a new story, they know very little about the business value and/or the technical details. The story serves as the spark for the discussion; the team and Product Owner start to dive into the narrative to identify what value the story is attempting to deliver.

Point A (The Aha Moment)

By this point, the Product Owner has described the business value of the story and why he/she is considering this for prioritization. Now, the team is starting to jump into the conversation and the Product Owner is simply facilitating. As an observer, you can almost ‘feel’ the electricity in the room.

Between A and B (Enjoy the Ride)

Welcome to the Backlog Refinement sweet spot! The story that was hard to discern in the fog, has emerged. The solution to the problem isn’t fully outlined, but enough is known where all members have an idea how much effort it will take. Now, the team is expanding the acceptance criteria, considering system dependencies, or maybe covering very high level design. But when does the team know when it is covered ‘just enough’?

Point B and Beyond (Diminishing Returns)

How do we know when our session has turned from productive fact finding to detail driven design? As a non-technical observer, it is difficult to ascertain when the conversations move away from important story refinement. Beyond this point, the team can still acquire valuable information, but it is not as impactful. When I’m observing or facilitating, I don’t want to interrupt a potentially groundbreaking discussion, but I also don’t want to get too far ahead of ourselves. This where I like to tie the illustration to a simple question.

“So, Where are We?”

With teams that traditionally venture beyond the sweet spot, I like to introduce the graph prior to a refinement session and explain why I’d like them to consider it. The emphasis for the session is to land somewhere between A and B- where we have just enough information. I encourage the team to be cognizant of where they are in the discussion.

  • Are we still learning about the story?
  • Are team members coming up with pertinent ideas that are furthering the understanding?
  • Are the acceptance criteria being updated?


  • Has the discussion started to die down?
  • Are we discussing corner case scenarios?
  • Has the conversation started to dive into full blown technical design?

If a team member feels that they’ve ventured into the latter, I’ve proposed one simple tactic: Refer back to the graph and ask, “Where are we on the refinement curve?” This quick question gives the team an opportunity to reflect on where they are in the conversation. If it is still valuable, then they’ll call it out and continue. If they feel they’ve ventured too far, they’re now aware. Anyone can make this check- beware of stepping on any ongoing conversations though. The goal is to improve the team’s self-awareness. They should be able to get a feel when they’ve strayed.

My Experience

I’ve tried this with a variety of teams with reasonable success. It is definitely not a magic bullet if your refinement sessions are sputtering. However, it is a solid non-traditional strategy. I enjoy giving teams these tools to solve their own challenges rather than telling them they’re doing it wrong. There’s much more potential for improvement when a team can self-correct, rather than relying on someone to make the corrections for them.