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.

Get Off the Field, Coach!

   Could you imagine the chaos if football coaches could run onto the field during a game? With that picture in mind, every time a ScrumMaster assumes control of a team, he/she is essentially all over the field of play. Though the boundaries in football are clearly delineated, scrum has no such luxury; if you’re the ScrumMaster, you’re in the daily mix with the team. Being so close to the action has many positive aspects, but it opens the temptation to pick up some bad ones as well. Some, but not all, ScrumMasters come from traditional roles- project, technical, and general managers. As Ken Schwaber states in Agile Project Management with Scrum: “The ScrumMaster is a leader, not a manager.” It is such a simple statement, but it embodies the shift these individuals must make from command and control to servant leadership.

   I like to compare the role of the ScrumMaster with a professional football coach. Like a football coach, the ScrumMaster is constantly driving the team towards continuous improvement, and he/she needs to know how the team will react to certain coaching tactics. Unlike a football coach, the ScrumMaster doesn’t have direct authority over the team; we have to carefully and tactfully find the right opportunities to mentor them. As a member of the team, I always wanted to jump in, help, make decisions, and protect the team from failure. The short term gains earned us small victories, but I unknowingly created a co-dependence that stunted the team’s ability to self organize. In this article we’re going to cover some basic questions and use the coach/team/football metaphor to highlight the connection between ScrumMaster and football coach.

Who runs the daily standup?

   The daily standup is the first point of inspection. In many organizations adopting scrum, the standup becomes a terrible carry-over ‘status meeting’ from waterfall processes. Even with experienced teams, it is usually the first pillar to fall. It is natural for the team to look specifically at someone- the ScrumMaster, tech lead, supervisor, etc.- to answer the basic three questions:

  • What did I do yesterday that helped the Development Team meet the Sprint Goal?
  • What will I do today to help the Development Team meet the Sprint Goal?
  • Do I see any impediment that prevents me or the Development Team from meeting the Sprint Goal?

*The Scrum Guide, Ken Schwaber and Jeff Sutherland, 2014,

   A ScrumMaster facilitates the scrum meeting, but the team does not report to the ScrumMaster. Yes, the purpose of daily standup is to answer the three questions, but the intent is to spark a conversation between the team members about the sprint. Think of the daily standup as the huddle right before a play; the team quickly inspects and adapts their current drive based on what they’ve observed. In this huddle, the team talks to each other about the previous play, necessary adjustments, praise their teammates, or even get on their teammates for poor performance. The coach/ScrumMaster stands on the sidelines watching for any impediments that need their attention that the team has no way of resolving.

tv4-daily-scrum   The objective is to have the team run the meeting and discuss the sprint. When I have caught myself running the daily standup or interjecting during the meeting, I have used a couple techniques to ease the team back to proper practice. In a newly formed scrum team whose members I had worked with for years, I merely stepped all the way to the back of the room and asked them to huddle around our radiator- tv monitor or board with the sprint backlog. As they discussed the sprint, I listened closely for potential impediments that I required my attention.

   Later, I joined a team that had been practicing scrum for several years. On my first day, I walked into the room and was met with quiet stares. They wanted me to lead the meeting by calling out each individual one by one. Of course, this was a bit of a shock for me; rather than rock the boat on the first day, I complied. Just think of how ridiculous it would look if you saw the football coach run onto the field for every huddle; this mental picture motivated me to make some adjustments. As time passed, I started introducing different nuances to the daily scrum that would eliminate the need for a central figure. For example, rather than call out the individual team members, I created an open floor segment. I hoped this would encourage each team member to jump in and discuss the sprint, when they felt read51loQrUFfVL._SX258_BO1,204,203,200_y. As expected, this was met with some resistance and uncomfortable quiet moments. I stuck with Lyssa Adkins’ advice in Coaching Agile Teams:

“The room gets so quiet you can hear crickets in the background. Uncomfortable silence pervades the room. Team members are not even looking at one another. In this moment, your greatest gift to them is showing that you are comfortable with uncomfortable silence. So, just stand or sit there, not doing anything, not demanding anything from them, but staying connected to them. Gaze at them, each one, gently. Give each person the silent invitation to step in and speak. Someone will.”

   Eventually, the team figured out the new format. For those on the team who were resistant, I took the time to do some individual coaching. I asked and listened why they thought this was a bad change. Overwhelmingly, I heard that the meeting was fully structured before, and now it was total chaos. With each concerned team member, I took the time to explain why I wanted to make the change. The standup is for the team, nobody else; they should run it how they see fit. Eventually, I intend to step away as full facilitator and let them run the scrum. Notice the small incremental changes over time. With a newly formed team, you can make swift changes; however, you will often be met with resistance from experienced teams, so be prepared to put on your coaching hat.

Does the team make decisions on its own?

   Think back to the last time the team faced a decision. What was their first reaction? If you are the ScrumMaster, what was your first reaction? Unless the decision had something to do with an impervious impediment, the ScrumMaster plays no part in the decision. Having a technical and project management background, I have to bite my tongue as the team attempts to solve problems I can easily figure out much quicker. Too often, I have watched ScrumMasters jump into the weeds and problem solve for a team. Their intentions are all good; they don’t want to see their team struggle. They’re not aware that they are running onto the field during the middle of a play!

   Let’s tie this scenario back to the football metaphor. Once the team breaks the huddle, they look at the offense/defense and start making adjustments. They have to recognize the change in schemes, variables they didn’t account for, or opportunities that present themselves. A coach cannot hi-res-151683539_crop_northdo all of this for the team from the sidelines. He/she has to trust that they have provided the necessary tools and information to handle this scenario. The goal is to allow a team to grow and learn to make decisions on its own. Peyton Manning, probably one of the best quarterbacks in history, is known for constantly reading his opponents and making constant adjustments. Listen closely to all the action and yelling prior to each play; the offense and defense are reading and reacting on the fly. The same principle applies to scrum teams; the team needs to feel empowered and ready to address problems on its own.

   In my personal experience, teams turn to their managers and leaders for decisions because they are afraid to fail. Legendary coach Bill Walsh famously stated:


   My April article mentioned how many speakers from the TriAgile conference kept referring to failure as an opportunity to learn and grow. Nobody wants to fail; no coach or ScrumMaster wants to see their team fail. Jumping in to save a team has valiant intentions; however, what a ScrumMaster doesn’t realize is that the pattern will continue to repeat itself. The ScrumMaster inadvertently has robbed the team of experiencing that failure and growing from it. I’m not advocating completely being hands off; when faced with failure, the coach and ScrumMaster have an opportunity to mentor their team on the root cause, the decisions made, lessons learned, etc. The hope is to prepare the team when they face the same or similar situation in the future. This is where models like the one developed by Jason Tanner come in handy.

Screen Shot 2015-05-15 at 2.14.33 PM


Am I adapting to the team, or am I forcing the team to adapt to me?

   A software development team, just like the projects it works on, is in constant flux. Teammates arrive to work happy, grumpy, sad, mad, etc. In an ever-changing environment a ScrumMaster can be the steadfast dam that holds back the flowing water, or he/she can be the river bank that pushes and conforms where necessary. A great leader can read his team, understand its strengths and weaknesses, and leverage all of that information to help the team’s performance.

AP931114054--nfl_large_580_1000   The winningest football coach in NFL history, Don Shula, won several titles in the 1970s with a ground and pound offensive attack. He had two running backs in Mercury Morris and Larry Csonka that were an excellent combination of finesse and power. He also had excellent quarterbacks like Bob Griese and Earl Morral; however, everyone knew that Shula was partial to a balanced running attack. In 1983, the Miami Dolphins drafted Dan Marino- the most prolific pure passer of his time. Don Shula could have stuck to his balanced run style offense, but he would have wasted the incredible talent of Marino. Instead, he adjusted his offense to his player; together, the duo of Don Shula and Dan Marino won 116 games together- the most as a quarterback-coach combination until it was finally surpassed in 2011.

   This is where I will place the final tie for the metaphor of scrum and football coach. To be truly successful, we have to adapt to our surroundings. After being the ScrumMaster for a young team and switching to one with years of experience, I learned that the same tactics cannot be used. Each team member reacts differently to different styles of coaching. With some, you can be more direct; with others, you have to take a nurturing approach. Like, Don Shula and other successful coaches, we must realize our team composition and play to its strengths.

Closing Comments

   Every time I feel the old command and control urge taking over, I envision what it would look like if a professional football coach ran onto the field during a game. Picturing how ridiculous that would look on TV makes me chuckle, and it also reminds me that I need to be mindful of the boundaries for my team. The questions and the metaphor help to paint a picture of what we’re doing to our teams when we abandon servant leadership. Ken Schwaber did a fantastic job defining the ScrumMaster role; contrary to popular belief, it is a role that is very difficult to grasp. The ScrumMaster will always struggle with the temptation to to jump into the fray with the team; however, we can make an equal or even greater impact on it from the sidelines.