[randomsearch]

The Startup way: make a list of features you want to build for your next "release" / deadline. Make that really minimal, what really matters to your users? Tell people you're doing the next "version" by that date, but don't go to far into specifics if you can. E.g. you can say you'll have feature x where there are variants of that feature x1/x2/x3 of increasing difficulty.

If you need to, build prototypes of the features to get a feel for how difficult they may be. Then you've got a set of features you _think_ you can get done by the deadline.

Write down the spec where folks can see it. The deadline should be say < 8 weeks away. No scope creep in that time. Stick to what you have.

Then get to work. One rule: you will ship at that deadline. You can actually ship individual features beforehand if you do CD etc. You can use feature flags to hide the features for most users if you want to have them feel like a "version" has been released. But that deadline is set in stone and you do not move it (you can allow say a week slack to be reasonable, but probably keep that to yourself if you're a manager and only use it if you absolutely have to e.g. a key dev gets sick in the final week etc.)

As the deadline approaches, things will go wrong. Keep the deadline. Cut the spec. Firstly, cut to simpler versions of the features. Second, start dropping features.

Ship. People will be annoyed you haven't shipped feature Y that got dropped. Gauge the response. Now for your next "release", Y or Z is top of the list.

After the deadline has passed, give folks a period to recover as you decide what's next, cut them some slack and then go again.

This is the only answer I have to estimation.

[fatnoah]

> Then get to work. One rule: you will ship at that deadline.

I think the happiest moment of the past 12 months for me was starting a job as a VP Eng and asking the CEO what they wanted most from the Engineering process. It was basically what you are saying. Pick dates and ship on those dates. Cut things if necessary, but regular shipment of improvements is the goal.

[mr3martinis]

There are two ways to approach the problem of inaccurate estimation:

1. set a date and trim scope to hit it 2. set a scope with an understanding that the ETA is truly estimated and subject to change

Either way, stakeholders and the team have to fully understand and buy in on the approach.

When the approach isn't clear or when you promise both scope and delivery date, it's a highway to the danger zone.

[randomsearch]

Interesting, but is the “date flexible” approach really workable? How does the rest of the business work if the deadline is May, then August, then the following year? At least with the fixed date method you know that a bunch of stuff will be shipped at that date, and you can always have an adjustable plan for eg marketing.