[vladgiverts]

Speaking to the task size point, I’ve found (via leading a number of teams and training many more team leads) it’s possible to decompose any task into smaller tasks so that every task is within a small constant factor of each other.

If it seems impossible for a given task, maybe because it’s particularly complex or has lots of unknowns, then no problem, simply create a “spike” task to research or prototype whatever you need to in order to decompose the big task into appropriately sized chunks (for your team’s idea of appropriate).

See you end up with a bunch of tasks that are all roughly the same size or are spikes of similar size, and you can have the very nice predictability and productivity that the author is speaking about.

(btw, I also agree that contact switches are never cheap for software developers, so it’s better to let them finish whatever they’re working on whenever it’s not too unreasonable to allow it)

[kqr]

This has been true in my personal research too. When projects are sufficiently decomposed, a "ticket" about implementing part of a project is generally speaking within the same order of magnitude.

However, this article is not talking about "tickets" but rather about the entire project. So that you may or may not be able to break the project down into roughly-constant chunks is irrelevant for the arguments of this article.

What matters is the size of the full project that you need to see through from start to finish in order to get business value out of your work.

(Yes, you can usually break down the project into smaller chunks too, so that you see business value quicker. However, these are rarely of constant size anymore, in my experience.)

[8n4vidtmkvmk]

you have to be careful about pushing out an early MVP for "business value". my company tends to do this but the MVPs are so far from complete that I'm skeptical we're even getting good data out of it