Having more (all) the tasks in a backlog from the get-go might make sense if we knew that:
a) requirements wouldn't change
b) priorities wouldn't change
c) we would be able to keep the understanding of the work throughout the effort
Then we'd just pull ticket by ticket and fill it with the details when we need it.
I've been doing it for 25 years, and I'm yet to see a project where the above assumptions would be true. I don't expect to see it.
Requirements always change. So do priorities.
We have this saying that our clients always know what they want. Until they see it. Then they know they wanted something different.
But even if that wasn't the case, the requirements change because we learn as we build the thing. The moment we know the least about a project is at its beginning. After that, we only know more.
So if things change, keeping more tickets in flight (even in backlog) means that every reprioritization, every planning, every pull to development costs more. Heck, we're bound to add work that's already there, but we forgot about it.
It's the cognitive load we add to so many activities every day.
And it doesn't even solve the problem of having better design because there's too much to remember.
Your intuition is right, though, when it comes to understanding the big picture. Not only architecture but also business. When every engineer on the team understands these higher-level goals it's so much easier to make sound decisions about design and implementation.
But for that we don't need dozens/hundreds of tickets in backlog.
BTW: I have a rule of thumb that on a physical board, there shouldn't be more than 100 items altogether. Our brains are incapable of meaningfully processing more. On a virtual board, it's even less, as our visual capabilities are impaired by screen limitations and crappy design of the tools we use.
FWIW, my rule of thumb was to avoid more than 3 cycles worth of stuff in view.
1) In Progress --> Started --> Completed: One cycle worth of WIP
2) Next Up: WIP for the next cycle (top third is highest priority, remainder is unknown priority until the cycle starts, these items are up for discussion)
3) Unscheduled backlog: Max count is less than 1 cycle worth of material
I've worked with small teams that can digest 5-10 "items/stories" in a cycle, for them there shouldn't be more than 30 items in view.
I've worked with larger teams that digested 30-40 items in a cycle and for them, seeing ~120 items was fine.
For larger teams, the work items tended to get broken down into smaller chunks as the communication overhead and carrying costs of implicit details was much higher.
How tactical, how coarse and how goal-oriented these work items are can vary widely by team/org interests and capabilities.
I think we could have "anticipated tasks" kept somewhere maybe not on the "board", and not being committed to (yet). Just raise awareness of what is the high-level view of where we are or might be going.
I agree that specifications always change. And that means it's good to be aware of what they might change to. Then we might more easily see how they might conflict with the current tasks, and thus in fact reduce the amount that specs would need to change in the future.
My argument is that forward looking ideas can be helpful, but they shouldn't be broken down into "tasks" until someone is prepared to make a concrete investment.
I've been doing it for 25 years, and I'm yet to see a project where the above assumptions would be true. I don't expect to see it.
Requirements always change. So do priorities.
We have this saying that our clients always know what they want. Until they see it. Then they know they wanted something different.
But even if that wasn't the case, the requirements change because we learn as we build the thing. The moment we know the least about a project is at its beginning. After that, we only know more.
So if things change, keeping more tickets in flight (even in backlog) means that every reprioritization, every planning, every pull to development costs more. Heck, we're bound to add work that's already there, but we forgot about it.
It's the cognitive load we add to so many activities every day.
And it doesn't even solve the problem of having better design because there's too much to remember.
Your intuition is right, though, when it comes to understanding the big picture. Not only architecture but also business. When every engineer on the team understands these higher-level goals it's so much easier to make sound decisions about design and implementation.
But for that we don't need dozens/hundreds of tickets in backlog.
BTW: I have a rule of thumb that on a physical board, there shouldn't be more than 100 items altogether. Our brains are incapable of meaningfully processing more. On a virtual board, it's even less, as our visual capabilities are impaired by screen limitations and crappy design of the tools we use.