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.

Reflection on Dude Solutions Tech Day 2016

Good things come in small packages! Yesterday, Dude Solutions did better than ‘good’; they delivered greatness in a box of donuts. No, they didn’t literally hand out a box of donuts; though their breakfast spread was quite amazing. In the true spirit of ‘openness’ and ‘community’, they revealed their recipe for scaling agile successfully. It came in an unexpected metaphor- a donut.

Every time you look, someone has unveiled the ‘next scaling solution. SAFE, DAD, and LeSS are just a few of the established and emerging frameworks. A few years ago Spotify unveiled their engineering culture videos, and everyone clamored to adopt their model. Though Spotify’s model has worked incredibly well for them, it may not be a good fit for all organizations. Richard Khor – ScrumMaster for Dude Solutions- amazingly summarized Josh Anderson’s recent podcast on the ‘Agile Donut’. Rather than spoil your appetites, I encourage everyone to listen to the entirety of the podcast for the full helping of the donut.

Dude Solutions graciously opened their doors and demonstrated how they cracked the scaling code for their organization. They revealed more than a model or framework; they freed organizations and agile practitioners from the shackles of committing to one framework over the other. Much like Jeff Patton’s 2007 article Kanban Development Oversimplified, Dude shopped around and found the best fit for who they are and what they do. Their framework is in a constant state of evolution. This general attitude towards scaling gives them the flexibility to make adjustments in the future.

Thank you to Dude Solutions for opening their doors and treating the attendees as part of the Dude family. I look forward to many more Tech Days in the years to come.

Holacracy, Zappos, Spotify, and All Things Self Management

I sat back anxiously as I sent the article describing Holacracy, to my father. To understand my anxiety, you have to know a little bit about my father’s background. My father spent 35 years with Hobart, 25 of those years in a form of management. As a young boy, I remember visiting my father at the office and witnessing with my own eyes his commanding presence and the tight-knit relationships he had with each of his employees. In my mind, he was the captain of the ship, and he was going to drive his team, his branch, his company to success. To me, my father exemplified the command and control model; I braced for his head to explode as he was reading the article.hammer-and-nails

As soon as he finished the article, he turned to me and said, “I completely agree.” Needless to say, it was MY head that exploded upon hearing that from him. He explained that over the years in a leadership position he found that command and control, or as he described it ‘Hammer and Nail’, only produces short term results. Let me expand his metaphor:

“Managers are misguided in thinking that they are a ‘hammer’ and the employees are the ‘nails’. A hammer drives a nail downward onto a surface; what happens when the head of the nail reaches the surface? It can’t go any further! The same applies for people. If managers continuously pound away at their employees then there is no room to grow; they only have one direction. Leaders, not managers, quickly realize that their purpose is to lift their employees and encourage them to grow. Leaders serve as the mentors/guides for their employee’s professional growth. He/she recognizes that the people make the difference.”

Set aside all the different agile frameworks, acronyms, sales pitches, etc. and examine what we’re trying to accomplish. At the heart of it all, we’re encouraging self organization of the teams. If team members are heavily constrained in what they can do, they simply won’t move in the direction of self organization and become highly dependent on managers.

Does it work?

It’s challenging not to get excited when you read about these leadership strategies. The success stories of companies like Spotify and Zappos, fuel the fervor and build the cases for other organizations seeking to make the leap. It cannot be denied that these models are on to something, and their success is no mere coincidence. They have proven that the top-down approach doesn’t stand alone in successful leadership methods. At the very minimum they have proven what many traditional organizations wrote off as impossible.

The Challenges

Adopting this view of leaders over managers comes at a cost. Steve Denning- one of the major leaders behind the Creative Economy movement, described some of the resistance at Zappos in his Forbes article (May 2015):

Not everything has gone according to plan. Critics of Holacracy—traditional managers who basically want Holacracy to fail— have seized on the fact that CEO Tony Hsieh said recently that his company had not “made fast enough progress towards self-management.” They were delighted to hear that when employees were offered several months’ severance pay to leave if they didn’t embrace what was happening, 14% opted to leave–a huge increase on the normal 1% attrition rate.”



Tony Hseih, CEO at Zappos

Larger, established organizations have a very hard time making the transition. Unlike other social movements in a large organization, grassroots momentum is not enough. The key to an organizational transformation is middle management. I’m zeroing in on middle management because they are the ‘interface’ between the executive hierarchy and employees. Middle managers feel threatened by these ideas- they fear that they will become obsolete. Driven by these fears they will outright shut their employees down and sometimes go as far as undermining their own leadership’s desire to change. When faced with possible dissension, Tony Hseih, CEO at Zappos, threw down the gauntlet in his now famous ultimatum to his employees: “Adopt Holacracy or Leave”. In this memo, Tony meticulously counters all the misconceptions and misinformation regarding self management. His ‘all or nothing’ stance might be a bit extreme, but none can argue about his conviction to self management.

chaos_vs_bureaucracySmaller companies or startups have less challenges because they don’t have the bureaucracy nor the history of traditional management engrained into their DNA. Self organization is built into their identity from the beginning. As Henrik Kniberg explains in the Spotify Engineering Culture Part 2 of 2, Spotify struggles with the balancing their base- culture- with Agile values to avoid chaos and bureaucracy; if given a choice, he says that they lean towards chaos ‘because it is better than being stuck in bureaucracy.’

Closing Comments

In nature, evolution is inevitable. Anything that cannot adapt eventually becomes obsolete through natural selection. Ask Kodak about their decision to stick to standard film over digital media or any brick and mortar video store why they didn’t create a digital or streaming service. The next form of organizational evolution is occurring right before our eyes. Companies like Zappos and Spotify are challenging the status quo. Holacracy and other forms of self management may not be the branded ideas that we end up with in 10 to 20 years, but they have been the catalyst for this new form of leadership. This movement could bring a new era for businesses globally- a self organized workforce and as my father explained that morning, ‘Leadership that liberates ideas through empowerment, support, and encouragement.’