I’ve heard a lot lately about how it’s not-so-Agile to set release dates for major features, epics, and projects. Some are uncomfortable being given a date (mainly teams) and others are uncomfortable without a date in hand (mainly, Product Owners, executives, and stakeholders).
This very much a myth to be dispelled. Dates do not go away with Agile! Rather, it is how we predict and communicate dates that should change.
With Agile, release dates are fixed based on time-boxed iterations. In our case, we tend to release after every sprint, so there is always a release date every two weeks. Therefore, by nature of time-boxing, the schedule is a fixed constraint. With the schedule being a fixed constraint (as is cost based on team size), it is scope that remains flexible. So, the scope that is included in any given release is flexible based on what the team was able to accomplish, what stories get dropped, what natural disaster impeded the team, who was out sick, and so on and so forth. Whether that scope accomplished is acceptable for release to production is always a Product Owner decision.
Second, what’s critical to understand is that in Agile we PREDICT. We predict dates for major features, epics, and projects. In fact, everything we do in Scrum is in support of us all getting better and better at predicting or being predictable rather … Capacity, story points, velocity, release planning, etc. Furthermore, the closer you get to any given date, the better you are at predicting it and the greater the confidence too.
With that understanding, how we communicate dates needs to be adapted for our Agile world. First, we should modify our language. Rather than say “Project X will be released on 7/1” let’s say “Project X is predicted to release on 7/1 and the team has an 80% confidence in that date”. Second, we should always remember that with schedule and cost as fixed constraints, scope is flexible. So, we might say “Project X 1.0 with A and B features is predicted to release on 7/1 and the team has an 80% confidence in that date”.
With some education around this topic we will all be better able to talk dates without the taboo of it not being Agile.
i.am.agile 
July 12th, 2012 at 3:26 am
Always a good reminder. I have heard a number of folks recently saying “I know Agile means we can’t have fixed dates…” Of course we can, but if scope is fixed, resources essentially fixed, AND the release date is fixed…you are in a bad space. Good post, thanks!