| > They need to know that, because they need to decide if it's worth it in the first place If this is the case, they should also be able to state the threshold above which the item would be "not worth it", and I would assume this is significantly easier to figure out than it takes developers to build a decent estimate. From a developer point-of-view, the first high-level estimate is then much, much simpler: "Is it going to take more or less than $not_worth_it to build?" If the answer is "more", then it gets dropped -- at least in its current state. It could be re-scoped later as a new item with a smaller MVP, for example. If the answer is "less", then the developer can put in the time to get a proper estimate. I think there might also be an argument that if the backlog is properly ranked the detailed estimate also becomes pointless -- just work on it until it's done. No one should be doing detailed estimates on items that are more than a few weeks/sprints away in the first place. Disclaimer: I've only recently been thinking about this abstractly, and have not yet tested this in practice, though I'd love to have this discussion with anyone that has. |
Which is essentially just as inconvenient for the business to estimate as schedule is for developers.
They are more important in the organisation, so they don't, and instead insist on perfect estimates from the dev team.