How do you communicate your release dates to customers?

Question

As a dev team we are under a lot of pressure (internally) to provide accurate release dates to our customers. How should we go about this?

The problems we see are in defining exactly what is required for each release and in not knowing how our priorities are likely to change during a release. We are using FogBugz and think that we can make use of Evidence Based Scheduling to help with the uncertainty, but we don't expect our customers to be very happy with a confidence range.

I see that Fog Creek have a policy of not telling customers when releases will be available until they are actually done. Does any one else take this approach?

EDIT: Thanks for the responses - very difficult to choose an accepted answer, so I voted a few of them up to give you the karma. I chose cowgod's as the one that matches the way I would like to handle our own development.

Answer 1

We take the approach of not announcing a release date until we are finished. If the customer needs it earlier, then we explain which portions of it are finished already and which aren't. Sometimes they are okay with only a core feature set, if it's the really important features, and are willing to wait for other features. In my experience though, they usually want to wait until the whole thing is done before releasing.

I'm lucky enough to happen to be in a culture where there isn't that much pressure for us to know in advance when our releases will happen.

Answer 2

Google does so too, not making available release dates.

Within a project there are three factors you may vary on, with regard to releases:

• Time
• Money/resources
• Number of features

With all regular yes/but/ifs about them (adding extra resources late in time naturally doesn't help your project).

If you have a fixed release date, Time is fixed. That way you can only manage your project properly if you vary the other two: by spending more, or limiting the number of features in your product.

Answer 3

If you are under such a pressure to let your customers know when you are releasing you might try some of the XP techniques like letting the customers decide which features they want first and doing TDD.

Answer 4

For the project I'm working on currently, we provide both a production release and a Quality Assurance (QA) release every week. If QA has approved the previous week's deployment, that will go out to production and our latest bug fixes and feature requests get packaged up for release to QA. We continue this process indefinitely.

We have a documentation Wiki that gets updated with the latest release notes that the client is able to view.

Answer 5

We don't provide a date. We simply ask them when they will be available to test our release. (This usually gives us plenty of time to wrap things up, since no one wants to test and they all have their own work to do as well.)

Answer 6

Just to give a different perspective:

We are given our release date!

For a large enterprise, you only can release an internal product the week-end, which means you quickly learn that:

a/ there is only 52 of them
b/ there is a lot of competition to reserve one of those (the logistic team is one of the competitors, for server and/or network upgrades, and prevents any release into production since the servers can be shutdowned at any time)

So we do not have the choice of the release date: we have only a few of those a year, and they are unlikely to change.

To still deliver a meaningful release we define a "top content" meeting a few weeks before the release date in order to define what will be actually part of the release (some current developments will not be in it, because they are proving to be too complex, or dependent on other parts which are not ready, or for any other "priority" change)

Then a Release Manager ensure that all teams merges the chosen developments on a testing environment for the all homologation/UAT/pre-production test cycle. (I skip a lot of details here)

And then we deliver. On time. (And then make some patches ;) )

Answer 7

The times when I've been involved in projects which accurately stated release dates, we have done it by dividing features into "essential for this release" and "can be slipped to next release", then choosing a release date such that we're very comfortable we can complete all essential features, and think there is at least some chance of completing all inessential features.

Of course this rather raises the question of why we're even considering the inessential features, but in a practical project there are usually several things which can be moved in one direction or the other, according to (a) whether the customer gets wind of the proposed feature and if so whether they like it, (b) how soon the following release is expected to be and how easy it is for the customer to upgrade then, (c) how your business plan is affected by, respectively, a saleable product now, or the Ultimate Product of Awesomeness next year.

So what actually happens is three categories, "essential and expected to remain essential: if this is not done on time we will be forced to release late", "treated as essential for now, but we may change our minds as the release date approaches", and "treated as not for this release for now, but we will pull it forward if time permits".

A lot of the projects I've been involved with, though, have been very long running, and interim releases are basically snapshots of the current working version. It feels like cheating to say you "gave an accurate a release date", when what actually happened is that a customer asked for an update, you checked your active bug list for that customer and saw that you had two outstanding issues that affected them, figured it'd take a week to fix both and do verification, and told them "we'll give you a drop in 1-2 weeks".

Answer 8

As the person who most frequently has to give the Fog Creek answer, I can say that our mouth wide shut policy is very smart, but takes some managing. Over the months, with management blessing, I've come up with something that works for me to not feel like a stonewalling member of a certain outgoing presidential administration, and helps to give the customer some context without making a potentially misleading commitment.

It's a matter of letting the customer know where we are in the process. Right now, I usually let them know that we're actively coding now, and that once we reach code-complete, which is some way off, we still have to QA, bug fix, QA the bug fix, and at least a couple of betas.

Example of what you might get if you ask me for a release date for FogBugz 7:

For FogBugz 7, we're actively coding, quite some time off code-complete, yet. If you have a particular issue you're concerned about, please let me know and I'll do my best to highlight it to the engineers or give you a status if we have one. Once we are to the code-complete stage, we still have to get through the process of QA, bug fix, re-QA, and beta. We're happy to let you know were we are in this process at every step, so you can track our progress, but we can't say for certain when the process will be finished.