Determining project releasing dates
A question that often comes up on Agile projects is; how do I determine when I can release software? For most project teams that are accustom to a defined process (Waterfall, RUP etc) it’s not immediately obvious how transition an Agile project from “Development” to “Production”.
I have put quotes around “Development” and “Production” because, within the Agile world, there is no concept of a “Development” phase nor a “Production” phase.
But regardless of Agile niceties, how do Agile projects go live?
Determining release dates with Agile
There are two ways in which Agile projects determine a release date, and there are pros and cons to each approach. The two approaches are:
- Specify a known date with uncertainty regarding around the feature set; I’ve called this a Fixed Date release, and,
- Specify a known feature set, with uncertainty regarding the exact date; I’ve called this a Fixed Feature release.
Fixed Date releases
In this approach, a release date is determined ahead of time and the team is committed to that date. However, no commitment is made to a full feature set. The best that the team can commit to are the highest priority items that the Product Owner requests.
Let us consider an example. If project Foo is releasing production-ready code at the end of each and every iteration, then it is reasonable to say that the project can go live as soon as the business feels the product (i.e., project Foo) has sufficient value. The following graph of earned value illustrates the point that I’m trying to make.
Even thought the team is not committed to a complete set of functionality, they will always be delivering the highest priority items. In this approach, I’m assuming that the project team will be working off a prioritized backlog. I do not feel that this is an unreasonable assumption considering this blog is about Agile software!
There is also an assumption that project Foo can deliver production-ready code at the end of each iteration. This is certainly possible, but difficult. It requires a much disciplined team who has embraced eXtreme Programming engineering practices (Continuous Integration, Test Drive Development, Refactoring). Even then, the software produced may not have been tested for performance, scalability etc.
In order to account for this, Scrum has the concept of a Stabilization Sprint. This is an iteration where the team is given the opportunity to perform any last minute testing and changes prior to going live.
Determining the release date by functionality
In this approach, a set of functionality is determined ahead of time and the team is committed to that functionality. However, no commitment is made to the delivery date. The best that the team can commit to is a range of dates determined from empirical data.
Let us again consider an example. If project Bar is consistently completing a number of functions per iteration and we have an estimate for the total number of functions for a release, then we can estimate a likely completion date. [More specifically we can estimate a range of dates between which the project is likely to be completed.]
The following graph of earned value illustrates this point.
This graph shows the gradual completion of work, but it doesn’t clearly indicate new work or functionality being introduced into the project team. A more useful graph is the Enhanced Burndown graph from Mike Cohn. This clearly shows new functionality (all work below the x-axis).
From the graph above we can estimate the the team will take between 6 and 8 iterations to complete the project. A full description Mike Cohn’s Enhanced Burndown graph can be found below .
It’s common for inexperienced teams to adopt Scrum, but fail to fully understand the necessary changes in behavior. Part of the difficultly with releasing by functionality is that Product Owners are not familiar with using the backlog to control project scope [via prioritization and multiple releases.] They’re accustomed to getting everything they ask for, so naturally they’ll continue to insist that everything is required.
This can lead to a failure pattern if the release date is predefined, but the PO is unwilling to prioritize and cut scope. In these instances it is necessary for the team to work closely with the PO to determine what can be released within the timeframe and to prioritize accordingly.
 Mike Cohn’s Alternative Burndown graph.