The definition of what’s “necessary” changes depending on your goals and the path the project takes, but it’s always important to stick to necessary work.

Many agile developers do get their most important things done when they need to, but they are lazy prioritizing the left-overs.

I just have seen it too often, that the execution was less of a problem than the scoping of the work. More than once I came across a product owner who just slammed a great team with plain stupid requirements and the biggest part of the problem were his expectations that everything gets delivered at once. In such a case introducing a backlog might help more than the other things.

I guess, it heavily depends on the situation in the project. I really like your approach and I think it’s a great idea to offer it as a real product.

I’m trying to avoid just handing people a whole methodology and saying “Here, you got Scrum.” They’re behind schedule and they don’t need to spend time on “methodology,” even a relatively simple one like Scrum. What they really need is to grab the easy wins first so management calms down and regains some trust.

Trust is a big deal when Projects Suck. Often, it’s impossible to “sell” what you and I might know to be the best solution if it doesn’t make things visibly better really really soon. Let them see some results first and then rely on their faith in more.

Anyway, yes, I like the idea of doing a backlog next.

I would add one more thing to the list: Sorting all requirements into a backlog. Get rid of priorities like 1a bold, red, blinking and decide, what shall come first, second, third, etc. This really forces the gold owners to understand that they cannot have everything at the same time.