"The notion that everyone should know everything is nonsensical". Does this include having frontend and backend-only developers in teams?

I was tying it back to the start of the conversation.

But that is my point. I would not use scrum to deal with standard requests of work, I would use kanban. But if I had to build something complex then regular feedback is invaluable when navigating complexity. That is what scrum is designed for.

If you are worried about writing shit code then build a smaller chunk of working software where the code isn't shit. Slice the value.

So you think businesses do have a bottomless pot of money allowing their teams to take as long as it takes to get solutions right with clean code?

I don't understand what point your reply is referencing @dariogriffo

Surely there has to be a time constraint at some point. Most businesses are not bottomless cash pots. Plus if you value earlier feedback then release and refactor after. Great code is worthless if the feedback is bad.

I think of the timebox as an investment. The business are investing in say 2 weeks of development. It means the team have a finite amount of time to find a solution, build, demonstrate it and learn from the feedback that comes from the demo. Do people panic during a hackathon?

I personally think it is a sound framework if used in the right circumstances. If sprints are used like hackathons where a team swarms around a goal to find a solution demonstrated with real working software within a timebox (sprint), then Scrum provides a framework to show how.

Haven't you just demonstrated where it might be appropriate, in the form of options. Whether you are then held to those estimates and punished for not meeting them is a different conversation.

I'm confused. Scrum does suggest that PBIs are user stories. In fact Scrum does not even mention user stories at all. Extreme Programming does, but Scrum doesn't.

7 items per day. How many people in the team and how small are there pieces of work? Because that is a high throughput per day.

Understood, thanks for the clarification @neil_killick .

Kanban has practices that can help manage the flow of value. Delivering valuable software, and working closely with users/customers is awesome, but they are principles you have chosen to use, that wouldn't change if you switch to scrum or XP or any number of frameworks/methods.

I like the principle, but I work with a team that slices their stories by user capabilities rather than releasable value. They then use the stories as historical data when using monte carlo forecasting. But I am guessing the stories you describe here are a standalone feature.

Yes but you did once write "The purpose of TDD is to design/build the code, not test it.".