I'm generally extremely allergic to time-based micro-estimation like this, but it sounds like you've got the rare healthy implementation of it. (Or as healthy as it can get, at least.)
Two questions, if you don't mind:
1. One of the biggest dangers of time-based estimation is the cultural danger around the "penalty for getting it wrong." It's got quite a lot of gravity to it, in my experience. Once there are time-based estimates for tiny bite-sized amounts of work, it's a hop-skip-jump to the toxicity of "holding people accountable for their commitments."
It sounds like you, as the team manager, are the one preventing this backslide. How do you think about maintaining a healthy culture around this when you go on vacation, get distracted, get promoted, etc?
2. What if a new discovery happens mid-week? Specifically, what if it's the kind of discovery that invalidates the current plan, so that finishing your "committed" work would be worthless (or actively negative) for the business?
I echo your concerns. On teams I've been on (exclusively at large, boring organizations), I've seen a tendency to create lots of really trivial tasks, and also to game things via pretending these tasks are more complex than they are.
It's easy to nail your estimations when you're operating at 1/3 your capacity, and you only ever meet but don't exceed the planned velocity.
I wonder if this also disincentives learning and innovation in the solution domain - because that would throw off all those estimates.
This is addressed by batching into same-sized chunks - the engineers discuss the work plan as a group and if you give yourself ten tickets that everyone knows are tiny and should probably be done in an afternoon, the group will ask you to group it into a parent ticket to make it a "half-day" chunk of work.
(1) This is part of blameless culture, and it can't work without everyone being bought in, so once it is established and working culturally it doesn't matter if one person on the team changes. In the same way that we "hold people accountable for incidents" by reviewing them and discussing what we could learn, we do "hold people accountable for their estimates" by asking what happened and reflecting on whether we could have seen that coming. But we're never perfect and we don't expect to be, we just try to see if we can get better over time.
(2) When something unexpected comes in you flag it and report it to everyone so everyone knows the expectations are invalidated. This is super important! I can't even tell you how much easier it is for a PM or other stakeholder to handle learning on Tuesday that the plan is not going to work than showing up for a check-in the next Monday expecting to see some deliverable and only then learning that it's late. The goal is to communicate expectation changes as close to real-time as possible, which builds trust and also helps the non developers see how volatile and unpredictable development can be so they learn to believe you when you say "the range is 10 to 30 weeks, and no I can't narrow it down any more than that."
Two questions, if you don't mind:
1. One of the biggest dangers of time-based estimation is the cultural danger around the "penalty for getting it wrong." It's got quite a lot of gravity to it, in my experience. Once there are time-based estimates for tiny bite-sized amounts of work, it's a hop-skip-jump to the toxicity of "holding people accountable for their commitments."
It sounds like you, as the team manager, are the one preventing this backslide. How do you think about maintaining a healthy culture around this when you go on vacation, get distracted, get promoted, etc?
2. What if a new discovery happens mid-week? Specifically, what if it's the kind of discovery that invalidates the current plan, so that finishing your "committed" work would be worthless (or actively negative) for the business?