I’m often surprised by how clearly and fully defining your goal actually liberates you when you need to define the solution to your problem. It’s almost like having too big a goal space constrains the solution unnecessarily
Engineers all make estimates. Some are good, and some aren’t. That’s hardly unique to software engineering. Just another way software engineering IS engineering.
Sometimes you have to accept two contradictory things as true. But what if they’re not as contradictory as you think? What if it’s just your perspective that makes it look that way?
It’s a marathon, not a sprint is a cliche, but it’s also true. You’re not sprinting to the finish line and then stopping. You’re getting to A release, not THE release. If you’re doing it right, there’s another one coming up, and many more after that.
Are you letting low priority work hold higher priority work hostage? If you are, are you doing it on purpose, or by mistake?
Similar to MMMSS, you can also break your tasks down further.
The hurrieder I go, the behinder I get.
You need to know where to step before you can worry about how far you’ve come.
Releasing with stablity is good. Waiting for release to get stability, not so much…
I got my attribution wrong, and you probably did too, but the point is just as valid.
Trying multiple things at once is NOT faster
As long ago as 1968, BDUF was a bad idea.
User stories need to live in the Goldilocks zone. Not too big, not too small