What kind of backlog review is this?

Question

Backsory
My company has recently hired a new product manager to handle a medium sized project. The new manager is a self-described "Scrum Master" but hasn't initiated any Sprint planning or other kinds of Scum-isms which I'm familiar with. Instead there is a new meeting which is either called the "Weekly Backlog Review" or "Backlog Grooming" meeting interchangeably by the new manager.

The meeting
The "Backlog Review" meets once a week with optional attendance. In the meeting the following is accomplished...

• Review all new Helpdesk & internal tickets
• Prioritize all new tickets
• (Sometimes) Directly assign tickets to developers

The Problem
In my experience neither a Backlog Review nor Grooming meetings are meant for any of the above purposes. I can't identify what this meeting is supposed to be or accomplish. To me, the meeting feels like an embodiment of the new manager's coping mechanisms with an unfamiliar product (Being that he/she is completely unfamiliar with this kind of software).

Question
Is there some actual kind of team-meeting in Scrum / Agile or just IT in general that does what I've described above?

Answer 1

welcome!

The meeting you describe sounds like the standard weekly or biweekly meeting that my org used before we ever heard of agile.

Perhaps it is a hangover from an incomplete agile transition? Or perhaps it is something this PM has added to the framework because they find it useful.

If it were me, I would go to the PM privately and ask how they see this meeting fitting into the Scrum framework. It might also be worth clarifying whether the PM is intending to run a Scrum project at all: just because someone is a SM doesn't mean that everything they touch will be Scrum, especially if there is resistance elsewhere in the project or org.

Good luck!

Answer 2

There is a Backlog Grooming meetings (a few years ago they changed the official name to "Backlog Refinement" but a lot of people still call it Grooming).

The Scrum Guide says this about Backlog Refinement:

Product Backlog refinement is the act of adding detail, estimates, and order to items in the Product Backlog. This is an ongoing process in which the Product Owner and the Development Team collaborate on the details of Product Backlog items. During Product Backlog refinement, items are reviewed and revised. The Scrum Team decides how and when refinement is done. Refinement usually consumes no more than 10% of the capacity of the Development Team. However, Product Backlog items can be updated at any time by the Product Owner or at the Product Owner’s discretion.

So the first two sound like they fit. This shouldn't completely replace all other events in Scrum - it's just one. Also, since only the development team should decide who does the work and how they do it, the third item seems off. The only exception could be if it is development team members deciding and then it wouldn't be strictly against the Scrum Guide, but I would caution that it's happening much earlier in the process than best practice recommends.

Answer 3

Also – "in my experience, every team that begins with a 'methodology' gradually evolves it into something that actually works." Gradually, manifestos like the Scrum Guide get pushed to one side while selected parts of its ideals continue to move forward.

Your manager clearly focuses on tickets, since these are concrete work- or change-requests that must not be allowed to accumulate. (Too many methodologies are content to shovel them into "technical debt" where they lurk, waiting to bite the project in the you-know. But, lots-and-lots of external stakeholders can usually see those tickets!)

So, don't be quick to tally these things up to "unfamiliarity with 'this kind of project.'" It's perfectly fine to at some point ask him-or-her how his-or-her approach matches up to the ideals of a methodology, but when you do, be prepared to listen. Carefully. Yes, presume(!) that s/he knows exactly what s/he is doing.

For instance, take with a healthy grain of salt such pronouncements as: "only the development team should decide who does the work and how they do it." Like it or not, "that's simply not business reality." In the real world, projects are impacted by a host of ancillary concerns "of which the project's own team – perhaps purposely(!) – knows not." Yet, within these carefully-sculpted boundaries, projects are able to efficiently proceed to their appointed destination because more than one set of people are looking out for them: both the team's own membership and those "pesky, oft-maligned" managers and outside stakeholders.

And, so, things about which we can say, "that's not the team's concern," are thus, precisely because "it is his/hers." A key role of any project manager is to act as the interface between the team and the enterprise. (As one long-ago colleague put it: "[almost...] not a single form of life on Earth would be here were it not for a placenta." Heh.)