1

We are following Scrum but our Product Backlog refinement meetings are not successful at all. The Product Owner (PO) presents a story and there are so many open questions and loose ends that we never manage to go through more than 1-2 stories in the session.

As a result many stories are refined while the Developers actually start work on them during the Sprint. I am not really clear what could be the root cause or how it can be corrected besides the fact that all main topic of the stories are completely unknown to the team until that refinement meeting before Sprint Planning.

What are common cases that cause this? I don't think this is expected following Scrum.

Improve this question
0

4 Answers 4

Reset to default
4

TL;DR: You're Missing a Definition of Ready

The whole Scrum Team should work together to define a standard Definition of Ready for both Product Backlog refinement and Sprint Planning activities, and should collaborate as a team to ensure that improperly-refined Product Backlog items (PBIs) are:

  1. a priority item at Sprint Reviews to create information radiators and transparency about the granularity and estimation problems to keep stakeholders informed;
  2. an urgent item at each and every Sprint Retrospective until the issues are resolved;
  3. are given space and priority within the Product Backlog itself if addressing the problem requires training, team capacity, or otherwise needs explicit inclusion in the project for scope, scheduling, or budgeting purposes; and
  4. items that aren't ready for Sprint Planning are either reduced to story spikes to assist with refinement or estimation in a future Sprint, or rejected from the current Sprint Backlog.

The rest of the answer explains how and why the Scrum framework requires these things, and recommends some of the things your team can collectively do about it within the defined scope of the Scrum framework.

Developers Can Gate Poorly-Refined PBIs During Sprint Planning

The Product Owner (PO) presents a story and there are so many open questions and loose ends that we never manage to go through more than 1-2 stories in the session.

The Product Owner is solely accountable for the Product Backlog, and the Backlog Refinement event is meant to ensure that stories meet the Definition of Ready for Sprint Planning. Note that Scrum itself doesn't actually use or define the term "Definition of Ready," although it's commonly used by agile practitioners to describe its related activities. However, the 2020 Scrum Guide clearly states:

Product Backlog items [often referred to as "PBIs"] 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. This is an ongoing activity to add details, such as a description, order, and size.

Please note that the refinement event—many agilists related to standardized refinement criteria such as INVEST as the Definition of Ready—isn't actually specified as a formal event in Scrum, but the related activities are referenced enough throughout the Scrum Guide that its lack of inclusion as a formal event should probably be considered an unintended oversight. Product Backlog refinement is where questions about issues with granularity and any item-specific Definitions of Done (DoD) should be called out. If the Definition of Ready, Definition of Done, or Product Backlog item granularity aren't sufficient for reasonable estimation during Sprint Planning then the Scrum Team should consider such stories as unsuitable for inclusion in the Sprint Backlog for the current Sprint.

Developers Should't Accept Unrefined or Inestimable Work into a Sprint

The Developers are explicitly empowered to select the work that will be included within the Sprint, and are therefore implicitly empowered to reject work for the Sprint that doesn't meet the Sprint Goal, or that is insufficiently refinable during Sprint Planning to fit within a single Sprint within a reasonable confidence interval. Planning Poker and other consensus techniques such as fist-to-five

See Also

Consensus Techniques

Improve this answer
1
  • Developers not accepting the stories solves the problem of not having surprises during the sprint. But how can we help as a team to no end up having to constantly push back due to so many unrefined stories? E.g. if a story is lacking information and the PO considered it as a priority for the next sprint, would a solution be to do another meeting on that story? But how would that scale to multiple such cases?
    – Jim
    Commented Apr 11, 2022 at 18:48
2

One interesting thing you said is that the "PM" presents the story. There is no project manager role in Scrum. The product owner and/or other stakeholders/SMEs ought to be present so that the team's questions can be properly answered.

If there really is insufficient time to refine stories then try to do the refinement earlier. Again the PO needs to be responsible for identifying priority items early enough that they are ready to go into a sprint. Make sure you have an agreed Definition of Ready - the set of criteria that defines when a backlog items is ready for work to begin.

Improve this answer
2
  • It is not possible to do the refinement earlier, because the PO along with the designer(s) think they should prepare the story as much as possible in advance but when the story appears it is revealed that there are "gaps" and open questions. So I am not sure what is the solution to that
    – Jim
    Commented Apr 10, 2022 at 21:14
  • 1
    Maybe he meant Product Manager? I've seen companies replacing Product Owners by Product Managers.
    – Tiago Cardoso
    Commented Apr 11, 2022 at 12:24
2

Refinement isn't a meeting. It's "an ongoing activity to add details".

Although I'd say that most, if not all, of the teams that I've worked with tended to have a refinement meeting where the Product Owner can present the most current state of the Product Backlog and go over changes since the last time and where the Developers can coordinate on if they believe enough of the top of the Product Backlog is refined and how to get enough refined, most refinement happens outside of this meeting. Rather than the whole team, individuals or small groups will break off and work on refining Product Backlog Items, meeting among themselves and including the Product Owner as necessary.

The amount of refinement necessary for starting work depends on your tolerance for risk. It's not necessary for a Product Backlog Item to be fully refined before being selected for a Sprint. The only condition is that "Product Backlog items that can be Done by the Scrum Team within one Sprint are deemed ready for selection in a Sprint Planning event". The team may consider additional criteria that helps them to have a successful Sprint Planning and execute on the planned work, but more refinement means less development time. It becomes a balancing act between refinement and risk reduction for upcoming work and development against the current Sprint Goal.

Improve this answer
6
  • "where the Developers can coordinate on if they believe enough of the top of the Product Backlog is refined" what my question is about is exactly this point. The fact that there is never any story at the top of the backlog refined adequately that would allow the developers to not have surprises about the story when they pick it up during the sprint. The question is not about "perfect refinement" but such lack of refinement that we can't even go through 1 or max 2 stories due to so many question marks
    – Jim
    Commented Apr 10, 2022 at 22:22
  • @Jim If you're only doing refinement in a whole team meeting, you're probably doing it wrong. A meeting is great for doing refinement, but each developer is probably spending a day or two's worth of effort each Sprint on refining things, meeting with the Product Owner to iron out questions about what is desired and the rest on just-enough technical design to be able to do the work in an upcoming Sprint. My rule of thumb is two Sprints worth of work refined, in terms of however you size or count Product Backlog Items.
    – Thomas Owens ♦
    Commented Apr 10, 2022 at 23:56
  • I didnt understand if your last comment is a suggested solution or not.
    – Jim
    Commented Apr 11, 2022 at 7:32
  • @Jim My previous comment and my answer are the same. If you're trying to do refinement in a single meeting, you're doing refinement wrong. There are many ways to do it, but one meeting with the whole team doesn't usually work. Define exactly what it means to be refined, get the whole team involved in refinement earlier, and spend more time refining.
    – Thomas Owens ♦
    Commented Apr 11, 2022 at 9:42
  • But it is not clear to me what exactly you are suggesting. Should we have multiple refinement meetings? Or a refinement meeting is meant for a future sprint instead of the upcoming one? Or something else?
    – Jim
    Commented Apr 11, 2022 at 11:34
2

There could be several reasons for an ineffective refinement session, such as:

Backlog isn't minimally clear and ordered

Team doesn't know the specific stories to look at; maybe several stories are being tried to be refined at once, wasting efforts

Team lacks business context of the problem being solved

The Product person* should come to the team what needs to be done, give some background on it and then leave the team to decide how. This work is collaborative, not exclusive from either side.

* Not sure if your team has a Product Owner, a Product Manager or a Project Manager to represent users.

Refinement is being converted into a full-scale waterfall analysis phase

Maybe the team is trying to break the story down to its minimal details? As Thomas mentioned, that's not the refinement purpose. His answer delves better into this aspect.

Time allocated for refinement isn't enough

There could be the case where the team has the skills and the info but really needs more time. Your mileage may vary, but it's also up to the team to make room for enough refinement room.

All things said, the best approach is to ask the team if they share the perception and what they'd like to do to experiment if this could be mitigated.

Improve this answer
4
  • "Maybe the team is trying to break the story down to its minimal details?" could you give an example of what you mean here?
    – Jim
    Commented Apr 11, 2022 at 18:49
  • If the team is writing an extensive amount of information detailing all the code changes that need to be done, then there's too much breakdown. It could be the case when there's someone more senior giving instructions to junior team members. If the team is not comfortable taking the item into the Sprint without some uncertainty to be discovered during coding, then it's a good opportunity to understand why. Maybe there's a blame culture and the team is just over-refining to cover themselves from blame down the road if they don't deliver a specific velocity of a given amount of story points.
    – Tiago Cardoso
    Commented Apr 11, 2022 at 22:35
  • No that is not the case. The question is about understanding what the story is about and how it affects/interacts other aspects of the product. Nothing related with implementation details
    – Jim
    Commented Apr 12, 2022 at 7:48
  • So, based on this comment it seems it falls into the "Team lacks business context of the problem being solved".
    – Tiago Cardoso
    Commented Apr 12, 2022 at 12:22

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.