Does anyone else have the problem where you are responsible/building so many things that grooming meetings almost become pointless? My team has so much we work on, that any single member of the team has very little context about things they have not yet worked on. As a result every grooming meeting turns into one person talking in a vacuum. There is a also a lot of everyone looking to me to explain everything to everyone else constantly, but I also can't keep up with every detail + dealing with the rest of my work. Efforts to get them to be more descriptive in epics and tickets have not gone well, with the complaint that "we spend too much time planning or writing" when I try to get them to describe the problem more. Exacerbating the issue is my team is literally across the hemisphere. I only get about two hours a day where they can all be in the same room. Often 80% of that time is consumed by other meetings or team rituals like sprint retro.

When people complain that they spend too much writing documentation etc I usually try to make them understand it's part of their job. Being an engineer is not just about writing code, especially not in big companies. If you have your own business sure, you don't need documentation, but if not you probably do. Apart from that we don't do grooming meetings so I don't know.

1. don't try to refine too much ahead, as you said people miss context and they'll forget the discussion when it's time to implement those things later 2. Is everyone working on separate things? Or they have individual tasks but a common goal?

1. I would like that but "the business" is on my case about, which is a fight I am willing to fight but...annoying 2. Usually multiple goals, rarely do we have something that we can have multiple in tandem work going on, it is usually 1 or 2 engineers working on separate goals and stories towards that goal

I worked for an organization who never wanted to throw an idea away, so we had 100s of backlog items. I worked with the people outside of the team to get them to pick the top items for a "next up" list. I started at 20 and over time reduced the "next up" list down. We then took the "next up" list and worked with the team to refine them, understand what pain was being solved, etc. Once we were cruising along with a small "next up" list, I started dotting the rest of the backlog each week (it was on a giant wall). The older something got, the further left I moved it. It let me show the stakeholders that ideas essentially had two common paths: 1. They were relatively new and quickly moved into development 2. They were old, got older, and never happened It was rare for them to select a 4-month old idea and put it in next up. On the rare occasions it did happen, it's because some external driver forced it (hello big customers!) This let me further convince them that anything with 10 dots on could be removed from view.

@Steve Fenton I do really like your approach, but unfortunately I have already culled the backlog significantly. I really love the vis though. The competing goals I have remaining are things I think we need......and so does everyone else

In that case, it's all about stack ranking and only breaking down the top items to reduce time wasted going over things that are further out.

Can I ask if you and your team have access to an enterprise AI tool like Gemini/chatgpt/copilot where you can use that to help refine tickets? My answer will change depending on that

A good simple pattern to complement the other approaches in this case could be a daily hour that is geo friendly for all, where refinement occurs on the priority items, which is only allocated by post standup call out the day preceding, as async mandatory refinement could cause more harm than good with those type of individuated work streams.. encourage a culture of short demos weekly (the more incomplete the better, sharing a vision is more important)

Funny you mention that @SeanOG I'm presenting that exact idea at a meetup tomorrow - we call them coworking, and they are 1 hour Monday to Wednesday, here's an extract from my way of working doc

@John Conneely We do not have access to any AI currently, company is very conservative on using it.

thank you @Ian Cullinane for sharing your challenges. I faced the same one some time ago. The things that worked for me are: • adapt the team topology (see the picture) • build DDOs (Distributed DevOps) around a certain Platform Architecture layer/pane with their own backlogs (but in sync) • build the role of Platform engineering technical lead with the purpose of having the holistic view and educate the teams • ….few other things I hope it helps. Good luck