Scope for Agile Projects with a Fixed Release Date
Fixed release dates are an obdurate fact for many organizations, particularly large ones. With potentially a host of different applications to update, fixed release dates have worked, and in many cases, have worked well, for keeping cross-impacted applications in synch by ensuring all the applications are tested together and released together. I’m not going to argue fixed release date's merits or weaknesses right now, I'm just accepting them as reality for the purpose of the rest of my argument. Tangent – I’ve seen 3 major and 2 minor releases a year as a popular release schedule, any other examples that work?
Project sponsors want to know how much functionality or how many new features for a product or application are going to go into each release. That’s a fair question. They’re investing in the project and want to know what they’ll get out of it. And they want to know several months ahead of time, if not half a year. But some agile teams I’ve worked with are hesitant to give those types of projections. “We’ll tell them what we get done in the last sprint,” is what I’ve sometimes heard. Try taking that to your project sponsors. We need to work together as a team to come up with reasonable estimates.
Since you have a fixed release date, you know the number of sprints you have until the release date. For each sprint, estimate the amount of work the team can do. A good way of doing this is with user Story Points. Story Points are an estimate of the work needed to complete a user story. Use the Fibonacci sequence for values you can assign to each story - 1, 2, 3, 5, 8, 13, 21, 34, etc. There are more sophisticated Fibonacci-like scales, but the important thing is that the scale is not linear. Experiment with what works best. Estimate the total amount of Story Points a team can get done in a sprint. Next look at the prioritized backlog and assign story points to each user story. Then go down the backlog list summing up the individual user story Story Points and you can estimate how much work you can do by the release date.
For example, if the team can do 100 Story Points worth of work in a sprint, and you have 6 sprints left until the release date, then you can do 600 total story points worth of work. Match that against your backlog. You still might not get to the answer that your project sponsor wants, but you will have estimates to make tradeoff discussions with. And a release isn’t an all or nothing event. You can release working code that you can build on for a later release.