[Ensorceled]

It's better than this actually. If they want a release by Christmas I can with, high certainty, tell them:

    Features will be in: A, B, C
    Features likely to make it in: D, E
    Features unlikely to make it in: F, G
    Nope: H, I, J
    Hell No: K, L, ..., ZZZ 

The problem I've always found is that, no matter what, you are going to be arguing with sales and management about E, F and L instead of them just working with A, B, and C.

[13hours]

Ask them to give you a guaranteed schedule of sales that you will hold them to. They'll say it's absurd, you can't predict that. Turns out it's the same with software dev.

If you find yourself arguing about this with management or sales, they're not trusting you to be the expert at what you do. Tell them that.

[shimon]

Actually it's remarkably similar. Sales has a pipeline of deals, and someone has an estimate of how much will be booked over the next quarter. This estimate is a key part of managing the sales team and is directly tied to their compensation.

Can you imagine if developers explicitly had a code quota to work to? We usually don't, for very good reasons, but salespeople certainly are held to delivery standards on work that isn't fully predictable, so you can kinda see how they might expect the same from software teams.

And the analogy continues to work. There is a pipeline of feature requests, some at the vague-idea stage and some nearly shipped. You can provide more accurate ship-date estimates for the nearly shipped ones. And a person with good judgment who knows the stakeholders can provide a better estimate than someone uninformed or unthoughtful whether we're talking about sales or software builds.

Further: sales has a bookings target, but also has the freedom to meet that target with various deals. Similarly, product teams will have launch targets, but need some freedom on what exact features are included because per-feature costs aren't predictable.

[paulddraper]

Have you ever done sales?

Sales quotas are extremely common.

[LoSboccacc]

I do the same, except they give me an updated priority list every month, and once the priority for the month are set they cannot be changed. Misc. fixes are done eating up the time from the low priority features.

It removes me and my team from the losing proposition of agreeing to get something done before any other thing, as nothing of value can come from that discussion. And anyone who tries gets immediately redirected to the wiki page for the next month feature list, which opens one week before the iteration starts, by which time we know which feature will be complete and which will get back in queue.

[alien3d]

because it treat as creative not engineering.In reality A can be expand to A1, A2, A3.The most issue would be, client paid for A future but not A1, A2, A3