Should management have a separate backlog?
I have joined a new company and management is using the same backlog that the product team is using. The product team is using traditional scrum and has a good understanding of it though they do need some guidance in some areas. Management was also using scrum which made no sense to me since they are not developers. I have suggested the use of Kanban for the management group that over looks the product team in their program since than. I have been getting some push back from management because they want to have one backlog that they can share with the dev product team. That request just does not sit well with me because managements backlog would be a list of things to check off and the scrum team would have a dynamic backlog that changes almost everyday. To me it makes more sense for them to have separate boards and backlogs. Management would still have access to the scrum teams board but their items would just exist on a Kanban board with its own backlog. The reason for this is because the Kanban cards that management moves are more impactful once moved. For example one card moved on the Kanban board to done would be equivalent to moving 20 stories on the dev teams scrum board. What does the community think?
I worked for an organization where every department in the company used Scrum. The Executives had their own Scrum Team with a Product Backlog. Their work was more strategic but it was done incrementally and in Sprints. The output of their Sprints often lead to work that would appear in other department's/team's Product Backlog. When I say every department, I mean every. Event Planning, HR, Payroll, Software Development, even the Facility Management group. And it worked VERY well.
A Product Backlog is meant to be specific to a single product. It is not a work management system. The Scrum Guide does not provide a definition of a product so the way a product is defined is up to the organization to decide. I have a hard time envisioning a situation where the management team would be working on the same products that software developers would. So having separate Product Backlogs makes perfect sense to me.
The Product Backlog is "an emergent, ordered list of what is needed to improve the product". It doesn't matter what the approach management is using to structure their work, if their tasks are not things that improve the product, the work doesn't belong in the Product Backlog. There's insufficient information to say if Scrum is appropriate or not for a management team to use, but I don't see why it couldn't be used if the conditions were right.
It does get a bit less clear when you start using electronic tooling. For example, if you can use filters to separate the work that is needed to improve the product from other work, then perhaps using the same backlog is something that can be done. In tools like Jira, for example, you can make multiple team boards configured appropriately for iterations or for flow-based work, workflows based on issue type, filters based on labels and issue types, and more where multiple types of teams could work in the same tooling. It tends to get more into effective use of the tool rather than improvement of the process.
I have joined a new company and management is using the same backlog that the product team is using
I'd suggest that management have a to-do list of the organizational impediments which are holding agile teams back. Good agile leaders will put themselves in the service of those teams by proactively seeking out such issues and dealing with them.
The removal of systemic and structural constraints to agile practice, which only management are presently empowered to do, should be the most important and urgent thing in their working day. If that isn't true, wonder why not.
the company I work at has got a separate log for the top managers. I have no idea whether this is right or wrong, but we're used to it.