[wikiman]

This 100% this. I run my teams via "Kanban" (I don't know how kanban it actually is, but that's what I call it).

The only question I ask around prioritization is "Is it worth doing?" If the answer is yes, I ask the stakeholder if they care how long it takes. If they do, I ask for a range and give a best estimate if it's achievable. If the answer is no, I ask why they care how long it takes if it's the most important thing to do.

My engineers know that they're expected to do that one project to completion, and we loop in other stakeholders (marketing, sales, QA, etc) progressively as we approach completion. Admittedly I work at a company of 20, but it works remarkably well, despite the absence of a "schedule"

[thaumasiotes]

> If the answer is no, I ask why they care how long it takes if it's the most important thing to do.

Well... would you rather get $150,000 two years from now, or $90,000 next month?

You generally don't want to be making any decisions off ordinal comparisons.

[conradfr]

You meet the PM/PO. They want to do Scrum, standups, retros, grooming, poker planning the whole thing.

Ask them to prioritize the tickets. Maybe they want some rough estimate to decide between some of them, maybe not (which is, suprisingly, in most case). During the same meeting you can groom the tickets.

The developers then start working on those tasks, when they are ready you release them according to your company policy and calendar.

By then everyone have forgotten about Scrum, management is amazed you release so much stuff, you can probably put all that in a one hour max weekly team meeting and everyone is happy.

I'm pretty sure that's applicable in a lot of pure player tech teams and quite scalable (I managed up to a 15 devs team this way but PR validation etc overtook the management part a bit much).

[edgarvaldes]

> don't know how kanban it actually is, but that's what I call it

We also work with a Kanban-like methodology. Basically a pull system with a hard limit on WIP.

[turk73]

Wow, I wish the Fortune 10 company I work for had this kind of insight! The "agile" process I work under is causing horrible outcomes. It's basically a sweat shop operation is what it really is. I'm a tech lead and am always fielding questions like "why did this take so long?" It took so long because there was unexpected difficult A, B, and C, two of the four guys on team are mid-level devs and not senior level, and so I worked a third night this week to try and pull this off. The sprint plan never makes it past 1-2 days each sprint and then I catch a bunch of righteous indignation with phrases like "you committed to this" and crap like that.

"Why can't we better estimate these things?" Because when I give honest estimates I get threatened by my boss. Your process is not reality driven.

"Can we break this work down into smaller stories?" No, I can't break down the final integration of all the parts into a smaller story. Or more commonly, they told me we have "too many stories" and can't keep track of them all when we break them apart.

The best is when a Product Owner or other business type says "I'm not a technical person." Then why the hell are you working in a such technical business and calling the shots on stuff you don't even understand?