[perfectritone]

I've heard over and over from managers that scrum is better at anticipating delivery dates. Even when the dates are consistently missed. They'd rather slow teams down with process so they can have a date to give their stakeholders, regardless of its accuracy.

[brezelgoring]

Managing the confidence of your benefactors is a big deal in business, I'd say you can make a career out of it alone, no other skills required. So in a sense you could say that Scrum is the businessman's brainbaby to handle engineering types.

[theshrike79]

You can calculate the team velocity pretty easily in Scrum (amount of story points completed per sprint) and from that you can estimate what gets done in what time.

BUT it needs the exact same team to be together on the same codebase. You add or remove people, the velocity changes. You change projects, velocity changes.

People also need to be honest when estimating tasks, don't be a 10x cowboy and say something is a half-day task when you know it'll take two days.

It's always better to pick too few tasks for a sprint than it is to take too many. You can always grab more stuff off the project backlog if the sprint backlog runs out mid-sprint.

[przemo_li]

In Kanban you multiply cycle time by tasks and do some modeling on that value. Only difference is that in SCRUM whole team does produce raw value upfront of work, while in Kanban manager computes raw value downward of work.

Raw value here refers to lack of statistical analysis.