This is why I push for Kanban whenever I am a PO. If we can ballpark an estimate, I can prioritize it. If we cannot ballpark an estimate, I can prioritize the research to clear out some of the unknowns. But most importantly, we set an expectation of rolling feature rollouts, not inflexible release dates. We communicate both internally and externally the next few things we are working on, but no hard dates. The article correctly identifies that hard release dates communicated to customers are the root cause of problems, so I simply don't give such things out.

▲

awesome_dude a day ago | parent [-]

Sorry, but how does Kanban come into this?

From your description, SCRUM, could work just as equally.

Don't get me wrong, I'm a fan of Kanban, it's awesome for visually presenting where bottlenecks are for tasks, but estimations aren't a feature of that.

But SCRUM maybe, where people are having a sprint planning meeting maybe more what you're thinking?

▲

TheOccasionalWr a day ago | parent | next [-]

Kanban in IT world in my experience implies approach where you focus on the work and tasks as they come based on priority. It doesn't imply what is on the board is finished strictly by some date, as the whole premise is that you can't really know.

SCRUM implies sprints where you agree in advance what will be actually pulled into sprints and delivered by the team so spillovers are not really expected / wanted.

	▲	awesome_dude a day ago \| parent [-]
		I think that we are agreeing that Kanban and estimates aren't really analogous

▲

ecaradec a day ago | parent | prev | next [-]

When working with kanban I maintained a average number of card done per days. if someone asked when some card woud be done, I just multiplied the number of card ahead of that one by average and get an estimate. You can estimate the cards but usually it doesnt really improve accuracy as tasks are on average the same size.

▲

a day ago | parent | prev | next [-]

[deleted]

▲

a day ago | parent | prev [-]

[deleted]