Backlog Refinement What does it mean to you?


So this question comes up a lot for some reason. During the Scrum of Scrums today had a interesting debate about what it means when a story is in “refined” status (or groomed for some of us that still use that term). Everyone seemed to have a different thought. They were not very closely aligned to each others definition. I would love to get others insight as to what it means to them and or there teams.
Here are some discussions I have had with other Coalition members …

@MattMorgis said : Our team has weekly grooming’s and then bi-weekly Sprint Plannings. When a story is in the “grooming” state, it’s getting the “As a user…”, acceptance criteria and story points to get promoted to the backlog.
During Sprint Planning is when we add the subtasks/hour estimates.

Looking forward to reading other responses.


I’ve never found much use for states and statuses. I’ve seen everything from “initial discussion” to “pre-grooming” to “grooming” to “pre-sprint planning analysis”… in a few cases, all of them were on a single backlog.

Seems unnecessary. In my experience, an abundance of governance and reporting rules obscures the three states that matter: To Do, Doing, Done.

“Backlog Refinement” might be a meeting teams use to enable an item to go from “To Do” to “Doing.” Whatever happens is what the team needs to achieve that outcome.

Or it might be a formalized meeting with certain rules about what happens, what is done, etc.

There isn’t a right or proper way. I prefer the former, though.


Thanks @zachbonaker… How do you teach or influence a brand new team to get a story into a “state” that is ready for sprint planning? How do you go about creating that discipline with in the team with out giving some guidance? Again asking out of curiosity to see how others approach this.


I recognize I’m not very helpful, but it’s difficult to have these asynchronous discussions. My answer to your questions is, “it depends.”

What is the state of the backlog to begin with? How involved are team members with writing initial stories? Is the team familiar with the product and/or codebase? What is the delivery cadence? What existing processes are working for/against the team?

There is a lot to consider. This may be why “backlog refinement” is a suggested “thing” in Scrum, for example, and not a prescribed ceremony in the framework.

And why I’m hesitant to say what I do to help teams in this regard. It’s rarely predictable.

Teams need a way to confirm the work is “just barely good enough” to get started on. They might use some pre-planning meeting (what gets labeled “grooming” or “refinement”) or they might build it into their system of work, e.g., writing backlog items in collaboration with the product owner.

Why not take it to the team? Coach them on the needed outcome (confirmation of work, slicing, etc) and ask them to discover the best way for them…


Yah I know not an easy question to answer. Why I thought I would post and see what others chime in with. My situation is complicated. 9 Teams all doing it different. I am not looking to solve that per say more about how to better answer the question to create better practices with in the team.

For me I think it helps build the team maturity especially with new teams. So understood its not a must have ceremony but I have seen it helpful in the beginning when teams are still new and bit dis jointed. I won’t post what the team suggested when brought to them… Lets just say it rhymed with smatter small


If the team prefers a phased system of work, have you considered focusing less on agile-like practices, and more on shifting the focus to learning agile principles?

This may be a stupid suggestion, as I have no context/observation of you or your teams… But without an understanding of principles (the why), people often fail to understand the practice, causing a good idea to “fail.” Then, once it “fails,” they have the (misguided) claim that, “we tried it; it doesn’t work.”


Jumping in with a stupid question; aren’t we talking about “Definition of Ready” here, and does the team have one? Regardless of the criteria you (the team) choose for your Definition of Ready, having actually discussed “What makes a story ‘ready’” and writing down the criteria the team comes up with goes a long way to ensuring the team is in synch when someone says a story is “ready” (a.k.a. “groomed”). This definition will of course evolve over time as you learn.

This gets a bit trickier across teams, but I’ve found that when teams post/publish their DoRs (to the other teams with which they interact), the other teams then have clarity, can “steal” ideas, and can challenge where there may be gaps. Same-platform teams tend to necessarily have very similar (or identical) DoRs incorporating platform constraints/idiosyncrasies.

I hope I correctly understood your question!



I believe that a “definition of ready” can assist teams, but is a practice that necessitates a deep understanding of Agile principles.

A “DoR” is very easily substituted for phased/gated processes that may exist. It can also suggest to team members that up-front design, documentation, process, rules, governance, etc. are helpful and/or necessary.

Just like I suggested to the idea of “backlog refinement,” ask yourself what the simplest way that might work could be. If teams simply worked in collaboration to write backlog content with product owners, the need for a policy of “ready” would be reduced. Putting a “definition of ready” in place creates a ruleset that inhibits the need for teams & product owners to work together before an item is documented in the backlog. Not only is this more complicated, but it speaks less to Agile values and principles.

That’s not to say the idea of a DoR is bad or wrong. I’ve found that a DoR can be a helpful mechanism to prevent pushed work to teams. But again, even if this helps a team, it’s a symptomatic response. I advise people to tread very lightly with the DoR concept/practice.


Agile is not without gates, and a DoR, DoD, and acceptance criteria are obvious examples. I view the presence of gates in agile as intentional and desirable. Gates aren’t intrinsically bad when they serve a necessary purpose; they’re certainly bad when used unnecessarily or excessively. In this case (and to your point), provided the team comes up with an appropriate, lightweight DoR in alignment with agile principles, a DoR can be (is) a valuable thing. But like much in agile, a DoR can also be easily misused, so be careful, and critically evaluate whether any given “experiment” you try as a team delivers benefit(s).

“Simple” is a good goal, though I like to use the word “best” (usually with an air quote flourish) when asking a team what approach it thinks might be… best. Meaning “What’s the best solution we can come up with, knowing what we know right now, and understanding that our interpretation of ‘best’ might change as we learn/experience more?” If simple is one of our goals (as it should be), “best” should incorporate this.


Semantics is a funny thing.

“Best” is one of the words I tend to avoid. I’ve experienced many scenarios where “good enough” delivered a higher value outcome than “best,” both in product and process.

By no means do I disagree with the spirit of your message. I just find it interesting how I sense feelings of pressure when considering the two questions:

“What’s the best [solution] we can come up with?” (pressure)
"What might we try here?"

I suppose semantics are in play with the word “gates,” too… the concepts you mention (acceptance criteria, definition of done, etc.) do not register as “gates” for me. In fact, they’re tools created for certain frameworks and methods… e.g., the team that best exemplifies agile principles, as I’m aware of, does not use “acceptance criteria” as oft prescribed.

Again, not arguing in the least. You are not wrong; I am not right. Rather, there’s a wealth of interesting dialogue here.


Great discussion. I think we are all in a bit of violent agreement. There are some concepts or guidance that can be used but there is not step by step and or check list… I have seen with new to agile teams the DoR can help build the discipline and give some parameters … The INVEST method. Also promoting story quality and not trying to shove to much into one single story.

While the team starts to gel together having those refinement meetings can help with better communication and help the team members understand how o break stories down and task. As the team matures this becomes less and less of a needed activity and or ceremony and just happens. It can also help the team push back on ensuring business value is being captured… Again great convo so far. Thanks for posting up…


Backlog refinement is getting people focuses on what need to be build. I personally would spend a little time each week to build up ready to pull work instead of doing it all during a sprint planning session. I find Using kanban to help young teams get work refined in an organized fashion. It helps drive agendas for the session. As team grow more mature this becomes more organic. If a meeting facilitates teams to get the Cards, Conversations, and Confirmation happening I am all for it. It can also be for good team building. Some best refinement session i have attended were not at the office at all. I posted on my blog about guerrilla grooming. Make it fun and keep it light !

Great points @zachbonaker and @Pete