[tharkun__]

I can second everything you said, really well described!

There's one thing that I would like to challenge though, which is high velocity and sprints. I don't think those two things have much to do with each other. When you work in sprints you just promise that you will get those items you start out with by the end of the sprint. But as items get finished, they can also be rolled out to customers already if you have that capability. This capability depends on other things than the sprint boundary though.

I've been in places where we deployed once every sprint. Also where we deployed once every quarter. And where we deploy once something hits the main branch. The difference between these places regarding sprints? None, all three used 2 week sprints. But they differed in how automated and integrated testing and deployment procedures were. Deploying once a quarter was at a place where "QA" wasn't fully integrated into the sprints. So while we had automated tests and manual testing in each sprint, deployment could only happen after "regression testing", which was a "throw over the fence to another department" process and deployments were manual and required down time. Deploying once it hits the main branch? We have automated tests and manual testing w/ a fully integrated system for every branch. Deployments are fully automated and run on a schedule that picks up anything that was recently merged to the main branch multiple times a day. Nobody has to touch anything after hitting the "Merge" button on that PR. So if something's done two days into the sprint, it will go out. Have a bug that you fixed and got QA'd 4 hours into the sprint? Customers can have it in hand around hour 5 into the sprint.