What kind of scope level do you think works when talking about that list? Like project level instead of tasks, and then engineering figures out how to deliver the prioritized project? Otherwise it kinda just sounds like a backlog to me, just curious how you see the difference there.
Also, I've seen product orgs that focus a lot of energy on not being burned, regardless of the scenario. They use their position at the crux of many communication channels to subtly shift blame around. Which is relatively easy to do when your role is complex and many-faceted.
It's going to invariably depend on how your company is organized, and its culture.
If you're at all able to start with something approaching the business-facing parts of Scrum, I think that's a great place to start. In Scrum, there are ideally two completely separate queues: The product backlog belongs to the business folks, and is organized in a way that works for them, and the dev team's list of tasks belongs to dev, and probably shouldn't look similar at all. And the only way for things to move from one queue to the other is during a regular meeting where the dev team says, "OK, it looks like we've got room to take on X additional work, what can you give us?"
And then, and I think this is secretly one of the most important things, the dev team physically creates new tickets for the new work they're taking on. You should never be able to just drag-and-drop tickets from one queue to the other. Ideally, it shouldn't even be physically possible to do so. Where I am right now, one is in $JIRA_COMPETITOR, and the other is an Excel spreadsheet. (If we all worked out of the same office, I'd probably go for an Excel spreadsheet and yellow sticky notes on a wall. Yellow sticky notes on a wall are awesome. They're a great deterrent to keep the PHBs from generating reports and dashboards for bothering people with KPIs.)
This little ceremony, and the associated firewall between two related but separate business functions, is, I think the heart and soul of what Scrum should be. It's the thing that sets up all the little firewalls and incentives that encourage business and dev to maintain a relationship that's more functional than dysfunctional. Everything else - sprints, story points, standup meetings, all that jazz - is just window dressing that some teams may or may not find makes that ceremony go more smoothly.
And if you can get a formal handoff like that in place, and get people to respect it, my (admittedly hopelessly idealistic) belief is that the rest of it gets easier to figure out. What's the correct scope and size of individual requests that the product people make of the dev team? Whatever size and scope best enables people to come out of the meeting feeling good about how it went.
But if everything's being jammed into one gimongous ticketing system, like all the ticketing system vendors seem to want you to do, you're doomed.
I prefer a single queue with simple rules of who can do what.
The approach I learned at Pivotal Labs was that product management decides the order of stories and bugs, since these add or subtract user value. Engineering can put chores anywhere in the backlog according to their considered discretion, since these reduce drag and risk. Each week you have the Iteration Planning Meeting to look at what's coming up. Each day engineering pulls whatever's on the top of the backlog and works on it until it's done.
If I am getting the drift right here, the root of the problem is that the Product Org is not prioritising well, and putting an upper limit on the total story points pushed in a release ?
That would lead to a large number of stories being classified as "Priority" and left to engineering to figure out how to deliver.
Separate Product Orgs, like or hate it, are not going away anytime soon. If anything, I believe they will become more ubiquitous.
Probably what we need is not more and better ticketing system, but better prioritisation systems, with well defined upper limits on how many story points can be released at once.
Thanks, this is a neat idea to think about. You helped me start anchoring some untethered thoughts I've had floating around about this stuff recently.
>like all the ticketing system vendors seem to want you to do
It's so annoying how misaligned the incentives are between these vendors and the users. Standard fare for B2B products focusing on the people signing the checks though...
> Yellow sticky notes on a wall are awesome. They're a great deterrent to keep the PHBs from generating reports and dashboards for bothering people with KPIs.
Wow! You should buy a .io domain name throw up a landing page and start selling this as a feature! (On a subscription model, naturally.) Seriously though I love this point.
Also, I've seen product orgs that focus a lot of energy on not being burned, regardless of the scenario. They use their position at the crux of many communication channels to subtly shift blame around. Which is relatively easy to do when your role is complex and many-faceted.