Scrum says:

Product Backlog items that can be Done by the Scrum Team within one Sprint are deemed ready for selection in a Sprint Planning event. They usually acquire this degree of transparency after refining activities. Product Backlog refinement is the act of breaking down and further defining Product Backlog items into smaller more precise items.

In case a PBI isn't trivial, a developer need some time to analyse the PBI, to look into the code base, to search some technical info in the internet, to compare possible solutions, etc. When are these activites done? Obviously they can't be performed during the current Sprint because this would put the current Sprint Goal at risk. So we need to schedule these analysis for the next Sprint. So we need two weeks approximately only to come back to the refinement of the PBI? And then, if the PBI's refinement gets finished, we will be able to schedule the PBI for the even more later Sprint. So we need two Sprints (or even more) to put the PBI at development. It looks to be very slow and not agile.

So how is refinement done?

4 Answers 4


The Scrum Guide was never very prescriptive about how to perform refinement. The November 2020 update removed one of the few pieces of advice that existed, which is that teams spend about 10% of each Sprint performing refinement activities. This guidance was deemed to be too prescriptive as teams were treating this as a rule and forcing themselves to this amount of refinement unnecessarily.

Refinement is typically done in advance of the Sprint Planning in which the work will be done, but very important Product Backlog Items may have been introduced at the most recent previous Sprint Review and the team may opt to attempt to sufficiently refine these items between the Sprint Review and Sprint Planning or at the Sprint Planning session.

My personal rule-of-thumb is that a team should have about 2 Sprints worth of work refined to the point of being ready for selection in a Sprint. How the team determines this varies based on how the team determines how much work to bring into a Sprint. If the team is estimating in hours, then about 56 hours per week of the Sprint. If the team is estimating in points and tracking velocity, 2 times the team's most recent Sprint velocity. This tends to balance between ensuring that there's a reasonable forecast of upcoming work to give stakeholders insight into what is coming next with not introducing planning and estimation waste. However, if there are extreme amounts of uncertainty, the team should consider refining less. If the organization is operating in a more certain and stable setting, it may be possible to refine more work, but I wouldn't go more than 3 or 4 Sprints worth of work.

How the team tactically executes refinement varies by team. I've seen a few different methods that have worked well.

One team that I worked with performed all refinement as a whole team, including the Product Owner. They would meet for a couple (~2 hours) each week and look at the top of the backlog, focusing on items not yet considered ready. They would be able to talk about the work, look through the code and identify any tech debt or pre-existing defects that could impede the work, identify dependencies or possible dependencies, decompose the work into units that can go through the whole life cycle, and estimate the work.

Another team only met briefly (less than 1 hour) every week or two. This meeting would identify what Product Backlog Items needed to be refined and people would take them on, as individuals or small groups. They would talk to the Product Owner and perhaps other stakeholders, get their questions answered, and begin to decompose the work into ways that made sense. At the meeting, the team would also review each other's work, make sure that everyone on the team had a shared understanding, there were no key unresolved questions that prevented the Product Backlog Item from being ready, and estimated the work. The amount of time varied per person and per Product Backlog Item.

Regardless of the specific tactical approaches, it's essential that the team should set aside time every Sprint to refine future work. No Sprint should be full to the maximum possible capacity of the team. My rule-of-thumb is that in a 40-hour workweek, 28 hours is the maximum productive work time. The other 12 hours account for overhead, waste, and slack. An organization should reduce overhead and waste, perhaps allowing productive work time to increase. However, there should always be slack. Slack not only gives time for refinement but also accounts for personal things that interrupt working hours or skills development or team building or something else entirely. Slack also supports things like enhancing the quality of the product.

  • 1
    This. The other golden rule I have heard is that the team should have seen a story 3 times before they get into sprint planning, so there's no ambiguity about the requirements, conditions of acceptance, artefacts/documentation required, and the size of the story. Commented Jun 27, 2021 at 19:45

A story needs to be "ready" by the time it is accepted into a sprint. The definition of ready varies per team and typically includes acceptance criteria but a fundamental point of being ready is that the team has enough information to decide whether a PBI can be completed within a single sprint. That doesn't necessarily mean that all the activities you describe have been completed in advance. It does mean the team has confidence that they can complete all necessary analysis, development and testing by the end of the sprint in which that PBI gets done. If not, the item may need to be broken down further.

Backlog refinement is often done well in advance of sprint planning and many teams will allow a certain amount of bandwidth per sprint to do refinement. Backlog refinement meetings (the "fifth ceremony" in Scrum) can also be helpful because refinement meetings help reduce the time that sprint planning takes. The difference between refinement and planning is that sprint planning only considers items for the current sprint whereas refinement takes in any items that the team think worthy of consideration.

Where a larger amount of analysis is needed it is quite reasonable to create analysis-only, design-only or "technical" stories. These tend to happen particularly during the early stages of a new piece of work. My advice would be to keep such items to a minimum and make sure they produce something that stakeholders can see and review during sprint reviews.


Here's what I do ... regardless of what the books may say ... because it works. I "make a refinement (research, plan development) sprint!" These sprints occur alongside(!) the usual, development-oriented sprints, but they're managed in the same way.

The purpose of this "parallel sprint" is to do the very-detailed research, requirements discovery, alternatives consideration, etc, that will be needed in order to determine what future "development sprints" need to be.

In my opinion, when a "development sprint" is launched, there should be essentially no question concerning what is to be done, how to do it, and especially, whether it is in fact the right thing to be doing. To me, this in-depth preparation process is easily handled as a parallel activity, and "sprint" methodologies help to avoid "analysis paralysis."

  • 1
    would you have a different team working on the parallel refinement sprint or would it be the same team doing both development and refinement?
    – nvogel
    Commented Jun 28, 2021 at 9:12
  • Alternatively, you could run a "Spike" sprint to do this analysis. Commented Jun 28, 2021 at 10:28

Do the analysis and refining while you're coding.

The whole point of Agile software development is to be flexible and open to changing requirements. As such, a minimal amount of preparation should be done up front, usually by making statements to the effect of "As a [role], I want [thing] so that I can [gain value]", working out what the Definition of Done for that item is, making a rough estimate of how much work it will take to complete that item, and getting the Product Owner to assign it a priority, usually by ranking it relative to other items in the Product Backlog and assigning a MoSCoW priority to it.

That's all you should need. Anything else? Figure it out as you go along. You should have accounted for that when you were estimating how much time it'd take you to complete the item.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.