In a few of our past projects, I encountered a situation that might sound familiar to you:
Developers are getting towards the end of a sprint. The product owner seems to have sorted the
product backlog a bit for the sprint planning meeting - he changed the backlog order somewhat
and pulled some items towards the top because he currently believes they should be added to the
product rather soon. He added some new things as well because the stakeholders demand them. In
the meantime, the team works on the development of the sprint backlog. The sprint ends, the team
does the end-of-sprint ceremonies and planning we go.
At the planning meeting, the team sits down to what seems to be a groomed backlog. They go
through the top backlog items with the product owner, who explains what he has prioritized. The
team members try to grasp the idea and technical implication of the backlog items and try their
best to plan them for development. But they find out that one particular story is very complex
and can't be fitted within a sprint, so they negotiate with the product owner about how to
meaningfully break it down into several smaller pieces. Another item has a technical dependency
on something that has not been done yet. The third item has a functional dependency - meaning it
won't work meaningfully unless a different story gets developed. The fourth item requires a
technology that the developers haven’t had enough experience with. Therefore, they are unable to
even remotely tell how complex it is. And so on it goes - the team members dig through the
“prepared” backlog, try to wrap their heads around it, and finally find out that they can't work
on every other story for some reason.
One possible outcome is that such items are skipped, and only the items that the team feels
comfortable with are planned into the sprint backlog. Another outcome is that they will want to
please the product owner and “try” to do the stuff somehow. In any case, the planning meeting
will take hours and will be a very painful experience.
In both cases, the reason is poor planning. If there ever was a planned approach by the product
owner towards the backlog prior to the planning meeting, it was naive, and now it either gets
changed vastly, or it gets worked on with many unknowns - making the outcome of the sprint a
What went wrong?
One might think all the planning occurs exclusively at the planning meeting. Why else would it be
called a planning meeting? Well, that is only half true. The planning meeting serves the purpose
for the team to agree on a realistic sprint goal, and discuss with the product owner what can or
cannot be achieved within the upcoming sprint, and create a plan of attack. Team members pull
the items from the top of the backlog into the sprint backlog in a way that gets to that goal in
the best possible way. It is a ceremony that actually starts the sprint, so the team sets off
developing the stuff right away.
In order to create a realistic sprint plan that delivers a potentially releasable product
increment with a reasonable amount of certainty, there has to be enough knowledge and/or
experience with what you are planning. The opposite approach is called gambling.
Definition of ready
It is clear that the backlog items need to fulfill some criteria before the planning meeting
occurs. These criteria are commonly referred to as a “definition of ready” (DoR). Basically, it
is a set of requirements set by the development team, which each backlog item needs to meet if
the product owner expects it to be developed in upcoming sprints. In other words, the goal of
DoR is to make sure a backlog item is immediately actionable, the developers can start
developing it, and they can be realistically finished within a sprint.
We had a good experience with creating DoR with our teams. However, we also found that this looks
much easier at a first glance than it is in practice. But I believe it is definitely worth the
effort, as it will make predictions and overall workflow so much smoother.
DoR is a simple set of rules which must be met before anyone from the scrum team can say “we put
this one into the sprint backlog”. They may be dependent on the particular product or project,
and they can be both technical and business-sided in nature, but I believe there are several
universal aspects to them as well. Here are some of our typical criteria for determining if
backlog item satisfies the DoR:
- Item has no technical or business dependencies.
- Everyone from the team understands the item's meaning and purpose completely.
- We have some idea about its complexity.
- It has a very good cost/benefit ratio.
- It is doable within one sprint.
There are usually more factors (such as a well-written story definition, etc.), but I picked the
ones that made us sweat the most to get them right.
Putting backlog refinement into practice
This is a continuous and never-ending activity, which in my opinion has the mere goal of getting
the DoR fulfilled. As usual, the goal is simple to explain, but in practice not easy to achieve.
Immature teams usually see refinement activities as a waste of time and a distraction from the
“real work”. Nonetheless, our experience has proven many times that if we don't invest
sufficient time into the refinement upfront, it will cost us dearly in time (not so much) later
in the development.
So, during a sprint, preparing the ground for future sprints is a must. The development team must
take this t into account when planning the sprint backlog. Refinement activities will usually
occupy a non-negligible portion of the team's capacity.
The product owner and the team should aim at having at least a sprint or two worth of stuff in
the backlog, which meets the DoR. That means there needs to be a continuous discussion about the
top of the backlog. The rest of the scrum team should challenge the product owner to make sure
nothing gets left there just “because”. Why is it there? What is its purpose and value in the
Once everyone sees the value, it is necessary to evaluate the cost/benefit ratio. The devs need
to think about how roughly complex it will be to develop such a user story. In order to do that,
they will need to work out a general approach for the actual technical implementation and
identify its prerequisites. If they are able to figure out what the size roughly is, even
However, from time to time, the devs won't be able to estimate the complexity, because the nature
of the problem will be new to them. In such cases, our devs usually assigned someone who did
research on the topic to roughly map the uncharted area. The knowledge gained was then used to
size the item (and also later on, in the actual development). This research work is also tracked
as a backlog item with it's intended complexity, to roughly cap the amount of effort worth
investing into it.
Now with the approximate complexity established, the team can determine whether the item is not
too large for a sprint. If it is, then back to the drawing board. How can we reduce or split it
into more items? In our experience, in most cases, a user story could be further simplified and
made more atomic to solve the root of the user's problem. Maybe in a less comfortable way for
him, but it is still a valuable solution - remember the Pareto principle. The product owner
needs the support of the devs to know how “small” a story needs to be, but he must be willing to
reduce it, and not resist the splitting process. All of the pieces of the “broken down” stories
are then treated as separate items with their own value and cost. But remember, there always
needs to be a user value, so do vertical slicing only!
Then follows the question: “Can't we do something with a better ratio between value and cost
instead?” In a similar fashion, the team then checks the rest of the DoR. How are we going to
test it? Do we need to figure something out in advance? Is there anything about the UI that we
need to think about before we get to planning? Have we forgotten anything in dependencies?
Have we taken all dependencies into account? Are we able to start developing it and get
it done right away?
Let the planning begin!
Once all the questions are answered, and both the devs and the product owner feel comfortable and
familiar with the top of the backlog, the team can consider itself ready for the planning
It is not necessary (and in our case was also not common) for all devs to participate in the
refinement process during a sprint. They usually agreed on who is going to be helping with the
refinement to give the product owner enough support, but also to keep enough devs working on the
sprint backlog. At the planning meeting, the devs just reassure themselves that they have
understood all the top stories in the same way, recap the approach to the development,
distribute the workload and outline a time plan for the sprint.
The sprint retrospective is also a good time to review the DoR from time to time, in case the
team encounters problematic patterns in the refinement process itself.
Proper and timely backlog refinement will prevent most last-minute backlog changes from
happening. In the long run, it will save money and nerves. It is also one of the major
contributors to the team's morale by making backlog stuff easier to plan and achieve.