When talking about Evolutionary Design and Delivering Value sooner some people hear "do a large thing fast and dirty then move on to the next thing" That's not quickness. That's haste.
Haste will slow you down every day after until you clean up the mess

I'm going to step into some unsettling territory and talk about estimates

Not if, why/why not, or when - but what

What are they?
What are the dimensions of an estimate? @tottinge once told me that estimates are made up of four parts: Effort, Interruptions, Risk, Unknowns

I've found that to hold pretty true
It also explains some of the usefulness and limits of estimation

I see people doing Scrum ceremony/events/meetings in a "by the book" way (or more often a popular interpretation) and completely failing to meet the **purpose** of those ceremonies Let's start with Iteration planning

The purpose is to limit work in progress.
Not to "see how much we can get done"/push as many clowns into the car as won't fit

If you can't reasonably use this to limit what you work on for the iteration period you are not meeting the purpose

Here is a big "secret" to better code. Writing tests first *doesn't guarantee better code* (it does make sure code is testable, can give better hints at intent, and often makes code safer to change)... Refactoring also *doesn't guarantee better code* (it's much more likely you'll have better code if you clean it up as you go, it's more likely to be changeable if separate out responsibilities, it's more likely be readable if you improve names as you have insights about intent)..