I suggest you ...

Include Backlog Refinement in the Scrum Events section

Backlog Refinement adheres to the definition of event (formal opportunity to inspect and adapt something.) Promoting it to event would make the guide tidier (presenting everything as a role/artifact/event,) facilitate the understanding and make it more difficult to forget it.
But it would be needed to slightly change the description of event since it states that everything is time-boxed; refinement would be an exception to this rule.

170 votes
Sign in
Sign in with: Facebook Google
Signed in as (Sign out)
You have left! (?) (thinking…)
Jose Luis Soria shared this idea  ·   ·  Flag idea as inappropriate…  ·  Admin →


Sign in
Sign in with: Facebook Google
Signed in as (Sign out)
  • Michael James (MJ) commented  ·   ·  Flag as inappropriate

    We should reduce prescription where it is not needed, and reduce changes to the definition of Scrum. Thus I would like to vote against this proposal.

  • Rune Funch Søltoft commented  ·   ·  Flag as inappropriate

    I don't think refinement is an event nor that it should be. I know a lot of teams that constrain this activity to an event but all teams I've worked with have as a part of them maturing made this more and more a recurring activity that happens practically every day and less and less an event

  • Ken Schwaber commented  ·   ·  Flag as inappropriate

    There are many techniques and procedures for accomplishing the work at team does before and during a Sprint. They fall within the realm of methodology: in a specific set of circumstances or context, this procedure (refining backlog in this manner) will assist in reaching a desired outcome. I look for people to come up with procedures like this. However, we won't bake them into Scrum. Look up Plimsoll mark. Add procedures, techniques, etc. to Scrum and it will go past its Plimsoll mark and won't be seaworthy.

  • Rolf Irion (MBA, CSP, KMP) commented  ·   ·  Flag as inappropriate

    I'm happy with PBL Refinement as an ongoing process/activity. But wasn't it an event (meeting) in previous versions (maybe called PBL grooming at that time)? And even if it shouldn't be one meeting per Sprint or week of Sprint but something the PO and DEV do several times per week, would that be so different from the Daily Scrum which is also an event? Given the characteristics of the other events one could ask: (1) how eventful can/should the PBL Refinement be (also compared to Part II of Sprint Planning for example), (2) does it make sense to time-box it and (3) Who participates? PBL Refinement is sth the PO sometimes does alone, most often does with the DEV team, can delegate partially to the DEV team and it could include experts, users/customers, etc. So it is probably rather comparable to working wiith stakeholders than with typical Scrum events. (?)

  • Richard Banks commented  ·   ·  Flag as inappropriate

    As many others have said - refinement is an activity, not an event. Much like testing and coding are activities, not events.

    Is it possible to close this idea as "will not be actioned" (or whatever status is similar to that) and return the votes to the people who voted for it?

  • Iain McKenna commented  ·   ·  Flag as inappropriate

    Product Backlog Refinement is an ongoing activity, not an event. I don't think I've ever seen refinement done effectively in a meeting :(

  • David Sabine commented  ·   ·  Flag as inappropriate

    I don't understand how this item has received so many votes.

    Please, NEVER make 'Backlog Refinement' an event. I fully appreciate that it's an informal and as-needed activity!

    In every case that I've observed a team holds a meeting for backlog refinement, it's to overcome an organizational dysfunction such as:

    - the stakeholders rarely speak or gather, so a meeting is created to bring them together.  An optimal solution (rather than a meeting for backlog refinement) is to experiment with ways to bring them together more frequently, informally.

    - people in "the team" aren't collocated, so a meeting is scheduled to bring them together. An optimal solution may be to experiment with ways to create discreet product mandates for each sub-team in their own geographic locations. (in other words, stop thinking they can work as a Scrum team!)

    - or people cut the Sprint Planning and other Sprint events short (to an hour perhaps for a 2-week Sprint), so a meeting is created to enable decision-making and consultation about the backlog. A more optimal solution would be to use the Sprint Events more fully -- use the full 4-hours for Sprint Planning every 2-week Sprint (or full day! for 1-month Sprints) to enable effective planning and backlog refinement at an existing 'inspect-adapt' point in the Sprint. (Another positive benefit of the long/full Sprint Events is that stakeholders and team are challenged to actually spend significant time together! This is difficult at first - so people give up and shorten the events - but they can and should get good at such collaboration.)

  • Anonymous commented  ·   ·  Flag as inappropriate

    PB Refinement is not a single meeting but a range of activities. A formal prescription would limit Backlog Refinement to a Scrum Team activity, that also can be implemented in various ways.

  • Joseph Little commented  ·   ·  Flag as inappropriate

    I am ok that PB Refinement is NOT included in Scrum. But, I would suggest some mention of it, that something in that area is almost always necessary, but we will not prescribe in Scrum how and when to do it. There is already some mention; I might be happy with that.

  • Udit Bhanu Singh commented  ·   ·  Flag as inappropriate

    Agree with Ken. Backlog refinement is situational and not necessary to perform this activity after every scrum. Better to continue keeping this as an activity within the framework...

  • Ken Schwaber commented  ·   ·  Flag as inappropriate

    Backlog refinement is so situational that it reminds me of the definition of done. I think of both as practices that depend on ...
    As we move forward, out goal will be to keep Scrum a framework that works for all software development, with its flexibility provided by the intelligence, diligence, and determination of the practitioners.

  • Forest Marie commented  ·   ·  Flag as inappropriate

    Gopinath Ramakrishnan - that would be FOUR ceremonies back to back to back to back. That's a lot. Some of us get off half of day Friday - have you considered that? We do backlog refinement as needed not to violate 10% of the Sprint capacity. That being said, I'm against promoting this to an event as it's already implied to be a JIT and optional event. No need to make it formal to the point we HAVE to have it every Sprint.

  • Karol Grodzicki commented  ·   ·  Flag as inappropriate

    There is already PB Refinement mentioned in Scrum Guide (page 13). I don't see a point in making an event of that - many teams work without such an event and still it's great Scrum.
    However, Backlog Refinement workshop could be mentioned as an example of Backlog Refinement implementation.

  • Mishkin Berteig commented  ·   ·  Flag as inappropriate

    I'm not keen on promoting it to an event. Most of the teams I've seen working well on this do it JIT based on the PO getting good info from the market, customers, users and stakeholders. Making it an event would prevent that natural conversation and further isolate the PO from the rest of the Scrum Team.

  • Melvin Pérez-Cedano commented  ·   ·  Flag as inappropriate

    I've seen many dysfunctions in Scrum implementations that trace back to lacking backlog refinement. Making this activity a first-class citizen event might help.

  • Gopinath Ramakrishnan commented  ·   ·  Flag as inappropriate

    I agree with this idea.
    Though planning is an ongoing activity & yet we have events like time-boxed Scrum Planning.
    Similarly backlog refinement is ongoing as an individual activity of the PO but still we need to have it as an event with the entire team participation.
    In fact I will go beyond this and suggest that this be scheduled as a time-boxed event (10 % of the Sprint duration) immediately after sprint retrospective and just before the next Sprint planning session of the next sprint. Scheduling backlog refinement meeting as an event will shift the team member focus from the current sprint to the forthcoming sprint. This will be a case of context switching which has been regarded as a waste from Lean perspective. But if a time-boxed backlog grooming is scheduled between two sprints the team can give full focus. So a typical 2-week sprint schedule will look like
    Monday -First Half : Sprint Planning and
    then after two weeks
    Friday - First Half: Sprint Review and Sprint Retrospective
    Friday - Second Half - Backlog refinement
    Monday - First Half - Sprint Planning (next sprint)

    One limitation with this approach is if the PO is not available on the Backlog Refinement Event is scheduled then it will get adversely impacted. But the same can be said of scheduled Sprint Planning session too.

  • Iain McKenna commented  ·   ·  Flag as inappropriate

    I agree that it's not an event but an activity. I too have seen much harm done by treating Product Backlog Refinement as an event (or meeting) rather than an ongoing activity.

  • Wayne Mack commented  ·   ·  Flag as inappropriate

    Let me provide an opposing viewpoint, as I find that these types of sessions may actually be detrimental.

    I have seen teams implement regularly scheduled "Backlog Grooming" sessions that mask an extended analysis/design phase prior to the start of the sprint. Some of the smells that arise include very large Product Backlogs, stories fully defined and decomposed prior to sprint planning, and short, low-value sprint planning meetings.

    Instead of having a pre-sprint grooming session, I usually encourage teams to have a full sprint planning session and to continue to have discussions of story details within the sprint.

  • Charles Bradley commented  ·   ·  Flag as inappropriate

    I'm not comfortable making it an event because in really healthy co-located teams, it need not be an event -- it can happen informally and organically. I like that it is a required activity with a time-box, without it being an official event.

← Previous 1

Feedback and Knowledge Base