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.
Richard Banks commented
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
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
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.)
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
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
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
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
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
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
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
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
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
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
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
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.
Jose Luis Soria commented
I know that it's not an event. That's why I'm proposing to promote it to an event.
Planning is an activity. It takes place at the Sprint Planning meeting event.
Collaborating about what was done during the Sprint is an activity. It takes place at the Sprint Review meeting event.
Inspecting and adapting are activities. They are done at the Sprint Retrospective event.
Synchronizing is an activity that takes place in the Daily Scrum.
Refining the backlog is an activity, let's create an event for it. I’m not even saying that it must be a time box or that it has to take place always at the same time. I mean that we should list it along the other events so it gets the same attention.
Joshua Partogi commented
It's not an event. It's an activity.