It's not that we estimated 6 weeks and it takes 12. It's that we get a bundle of tasks up-front and are told "it's going to take 6 weeks" for reasons that are negotiated at a higher level than our pay-grade. It's my situation anyway.
The core idea I took out of Agile is that once the high-level estimates are completed, the developers are meant to break them down into bite-sized tasks, put estimates on those, and prioritize them in a backlog with the project manager, customers, and any stakeholders. (In my case we're not building products to go to market with, I work in Higher Ed. We're building solutions for campus partners. So it's not really "Project B will bring in $Y," it's "Project will further our mission and better enable some common workflow." Not to go off-topic...)
What's happening instead is, we get the high-level tasks and then break the projects down into bite-sized chunks, then estimate the parts, and are told "great, now make that fit into 6 weeks, because that's all you have."
Developers don't estimate in hours or days, they use points or t-shirt sizes, because honestly, we do suck at estimating. It's not what you pay us to do. (I mean this honestly, it's really not. This is what they pay project managers to do, and they're literally a pay-grade above us.
And they don't write code, though they may be good at math and judging t-shirt sizes. The better ones also know how to keep their poker face, when meeting with the customers. But if your project is slated to last only 6 weeks, chances are you won't even have access to a PM. You wouldn't want one if you could get one, since 6 weeks is hardly enough time to plan and later change course. What would they do?)
T-shirt sizes are better than estimates at a sprint level too, because all you're really doing is horse-trading. If a feature is XXL according to the devs, maybe it moves to the back of the queue in favor of something that costs less and is worth more. That's what you do at Sprint Planning.
Back to devs, we're experts at writing the features, and sometimes we can tell you how long it's going to take and get that right, ... and sometimes we can harmonize in concert with the project leadership, but that's not our core competency. It's just moving faster, and doing it better. Sometimes you find out that the specs are wrong after the project has already started, and it's going to take longer.
We know that some projects are going to take a year, and some are going to take two. And those projects get project managers, and they are frequently delivered on time, with all of the promised features in them! Six weeks isn't an estimate, it's a budget. (And it's not a real budget, hardly even registers on the balance sheet. It's more like an experimental timeline.)
The problem is, customers prefer that we blow the budget rather than delivering part of a product on-time, even if it might have turned out to be enough. They're not willing to put things in order of priority, take an honest look at what will take 6 weeks to deliver, and settle for that. They'd rather cut corners, and then we allow them to make those concessions. Only they don't really want concessions, so we wind up having to spend extra time papering over the gaps.
"The core idea I took out of Agile is that once the high-level estimates are completed..."
This is not a core idea of Agile. The high level estimates are not part of Agile- fixed scope, time, and cost is the opposite of agile. You are just doing extra fake work around what is a fixed design process.
"Developers don't estimate in hours or days, they use points or t-shirt sizes, because honestly, we do suck at estimating."
No, they don't estimate in hours or days because those are commitments that are used against them- regardless of whether they are expected to attend other company meetings or other priorities are thrust upon them. Points or sizes are intended to be complexity or quantity of work estimates, which could take different amount of time.
In addition, estimates, whether of time or complexity, have uncertainty. Many enterprises are unable to deal with uncertainty.
If you fix cost and time as part of the budget, what you are left to be flexible on is scope. This is the most natural place for flexibility, as there is are often a wide variety of implementation choices that limit cost and deliver a low budget version of a feature versus one that would require more time.
> This is not a core idea of Agile. The high level estimates are not part of Agile- fixed scope, time, and cost is the opposite of agile. You are just doing extra fake work around what is a fixed design process.
In the first edit of this comment, before I submitted it, I said "we don't really do Agile, we do Agile-Lite" – I cut this line because I've heard this repeated by leadership and I've asked what does it mean, and never got an answer. I almost wanted to include it, so maybe I understand now!
Developer teams are Agile. Dev leadership is Agile-lite.
> The high level estimates are not part of Agile- fixed scope, time, and cost is the opposite of agile. You are just doing extra fake work around what is a fixed design process.
Leadership tries to fix scope, time, and cost on the long-term calendar because we want to deliver predictably, to not appear unpredictable or unreliable. As much as I tell upper management that you can't have fixed scope, time, and cost, they persist in trying to fix all of those.
And their budgets and goals seem to win over my objections, damn near every time!
I'm not doing extra fake work, I'm taking direction from senior leadership. Their work may be fake. Your opinion on their fake work, is duly noted, and I'm going to decline to state whether I agree for political reasons (in so many words, I like my boss and I rarely get time of my own to interact with the bosses boss.) I try to do my work and not rock the boat. Which is why I might get a demand to do something in 6 weeks that is clearly going to take 12, and just do the work. "We'll be given the extra time when we need it." That's healthy, even if it's somewhat dishonest.
> No, they don't estimate in hours or days because those are commitments that are used against them- regardless of whether they are expected to attend other company meetings or other priorities are thrust upon them.
That's a fact. But at some level, if you have this toxicity in your culture, someone is going to have to translate from t-shirt sizes into hours and weeks at some point, and when these estimates turn out to be wrong, someone's head will have to hit the block. (Hopefully theirs and not ours.)
I'd like to think that doesn't actually happen here, and also that's not why we use t-shirt sizes. Maybe just why your team uses them. Or maybe I'm just naive about it.
The core idea I took out of Agile is that once the high-level estimates are completed, the developers are meant to break them down into bite-sized tasks, put estimates on those, and prioritize them in a backlog with the project manager, customers, and any stakeholders. (In my case we're not building products to go to market with, I work in Higher Ed. We're building solutions for campus partners. So it's not really "Project B will bring in $Y," it's "Project will further our mission and better enable some common workflow." Not to go off-topic...)
What's happening instead is, we get the high-level tasks and then break the projects down into bite-sized chunks, then estimate the parts, and are told "great, now make that fit into 6 weeks, because that's all you have."
Developers don't estimate in hours or days, they use points or t-shirt sizes, because honestly, we do suck at estimating. It's not what you pay us to do. (I mean this honestly, it's really not. This is what they pay project managers to do, and they're literally a pay-grade above us. And they don't write code, though they may be good at math and judging t-shirt sizes. The better ones also know how to keep their poker face, when meeting with the customers. But if your project is slated to last only 6 weeks, chances are you won't even have access to a PM. You wouldn't want one if you could get one, since 6 weeks is hardly enough time to plan and later change course. What would they do?)
T-shirt sizes are better than estimates at a sprint level too, because all you're really doing is horse-trading. If a feature is XXL according to the devs, maybe it moves to the back of the queue in favor of something that costs less and is worth more. That's what you do at Sprint Planning.
Back to devs, we're experts at writing the features, and sometimes we can tell you how long it's going to take and get that right, ... and sometimes we can harmonize in concert with the project leadership, but that's not our core competency. It's just moving faster, and doing it better. Sometimes you find out that the specs are wrong after the project has already started, and it's going to take longer.
We know that some projects are going to take a year, and some are going to take two. And those projects get project managers, and they are frequently delivered on time, with all of the promised features in them! Six weeks isn't an estimate, it's a budget. (And it's not a real budget, hardly even registers on the balance sheet. It's more like an experimental timeline.)
The problem is, customers prefer that we blow the budget rather than delivering part of a product on-time, even if it might have turned out to be enough. They're not willing to put things in order of priority, take an honest look at what will take 6 weeks to deliver, and settle for that. They'd rather cut corners, and then we allow them to make those concessions. Only they don't really want concessions, so we wind up having to spend extra time papering over the gaps.