Scrum Sucks

> capture total velocity every 2 weeks and eventually use the avg for future planning

This aspect of scrum has never made sense to me. Planning with average velocity turns points into an obfuscated time estimate - why use points at all?

When you point a "0.5" and your team points a "5", stop and discuss the discrepancy until an alignment can me found. Keep doing that, every task, until you a collective meaning of "a point" is found.

Personally:

* Less than 1 - These are a smell and should not exist. These misalign incentives and encourage "bike shedding".

* 1 point tasks - no task that requires 2 people (dev and qa) is a 1-pointer, so this is something that needn't be QA'd. 1 point tasks should be rare items that can't be a subtask of a "real" task.

* 3 point tasks - These can be done in a day (depending on the team's opinion, this might be multiple people and still be 3 points). Virtually every task should be a 3.

* 5 point tasks - These are tasks that cannot be broken down to be done in a reasonable amount of time. These are generally things that have minor external dependencies. ("not hard but I'll have to get a server spun up by the unix admins.")

* 8 point tasks - These are rough tasks that haven't been fully dissected by the team and are the scrum version of a "code smell". The team should break these down and dissect them.

* 13 point tasks - "There be dragons here" tasks. Large unknowns and these tasks should not be added to a sprint until they're broken down further.

Literally to remove the forwards from the play after a restart, by having them all bound together with their arms twisted around each other.

Then, when the ball pops out, the field of play is nice and empty for a few seconds and some running rugby can take place, while the forwards slowly untangle themselves from the scrum.

To translate to software engineering and agile, if scrum is taking half of the team's developers and tieing them up and preventing them from doing any work, then scrum is working exactly as intended.

Scrum is bad (as implemented by bigcorp), but waterfall is worse (as implemented by bigcorp).

A simple example from my past. My team was scrum based in a bigcorp that mostly did waterfall, so of course we did scrum badly too. That said, our scrum team shipped a major integration feature in two sprints (4 weeks) that the partner integrating team inserted into a 14 month long waterfall release train. It took ~16 months to ship a feature to customers that took 4 weeks to build and internally validate.

If there had been less bigcorp bullshit said feature might have taken 3 days, but at least 4 weeks is better than 14 months, although in this case customers got the worst of both.

Agile is not going to help you better track a project that the rest of the company treats as waterfall, fixed date, fixed scope shit.

99% of the ranting about Scrum or whatever is about typical shit project management, that they've bolted agilish lingo to.