Release planning
Release planning decides which features go into which release, across a sequence of releases, under limits of effort, budget and dependencies [1]. A release is “a collection of features that the customer values”; the plan commits firmly to the next one and sketches the rest [2].
1. Release or iteration
A release is what the customer gets: “a coherent deliverable to customers or users”. An iteration, or sprint, is how the team gets there: “a short-duration, timeboxed iteration”, and “a release is typically composed of multiple sprints”. Rubin gives typical ranges of three (or fewer) to nine months for a release and one week to one calendar month for a sprint [3]. An iteration must end in working software; a release must be useful. Some teams release every timebox, as one e-store did every three weeks [4].
Rubin 2012, Fig. 18.1.
Both are timeboxes, so in both the date holds and the scope moves. Take Quill, a fictional word processor due for its publisher’s spring list. After the third sprint’s demo the customer moves comments above mail merge. The change waits for the next sprint’s planning, the customer decides on value while the team advises on cost and risk [5], mail merge drops below the release line, and the spring-list date stays put. Moving the date is the sponsor’s separate decision, never a side-effect of reprioritising.
Releasing early also changes when the money comes back. In Denne and Cleland-Huang’s example, one year of development has a net present value of −$24K as one release and +$205K as four quarterly ones [6].
2. Approaches compared
| Approach | What it optimises | Inputs needed | Main cost |
|---|---|---|---|
| MoSCoW [7], [8] | a guaranteed minimum plus contingency | a category per feature; Musts at most 60% of effort | the Should/Could line is judgement |
| Buffered MoSCoW [9] | delivery certainty by a fixed date | the customer’s order; a normal and a safe estimate per feature | conservative; promises stop at “short of a calamity” |
| Cost–value (AHP) [10] | value per unit of cost | pairwise value (customers) and cost (engineers) judgements | n(n−1)/2 comparisons; ignores dependencies |
| EVOLVE [2] | stakeholder urgency against business value, increment by increment | weighted stakeholders’ ranks; effort; precedence | data collection; a person picks among several plans |
| IFM [6] | the project’s net present value | Minimum Marketable Features; cost and revenue per period | per-feature revenue forecasts from the business |
Buffered MoSCoW simplifies SPID, which plans the first increment at about 95% confidence and re-plans it at 50% [11].
3. Pages
| Page | The question it answers |
|---|---|
| Prioritising features | When not everything fits, what goes in first? |
| Buffered MoSCoW | How many features can a fixed date honestly promise? |
| Contracts and incentives | Who pays when only part of the release arrives? |
How solid is this?
- Where it comes from. Rubin’s ranges are typical values from practice. Denne and Cleland-Huang’s project is hypothetical.
- What is thin. Of 24 published release-planning models, four have reports of full-scale industrial use [12].
Acknowledgments
This page adapts material from lectures by Eduardo Miranda [13] on software project management.
References
- G. Ruhe and M. O. Saliu,“The Art and Science of Software Release Planning,” IEEE Software, vol. 22, no. 6, pp. 47–53, 2005, doi: 10.1109/MS.2005.164.
- D. Greer and G. Ruhe,“Software release planning: an evolutionary and iterative approach,” Information and Software Technology, vol. 46, no. 4, pp. 243–253, Mar. 2004, doi: 10.1016/j.infsof.2003.07.002.
- K. S. Rubin,Essential Scrum: A Practical Guide to the Most Popular Agile Process. in Addison-Wesley Signature Series (Cohn). Addison-Wesley Professional, 2012. [Online]. Available: https://innolution.com/essential-scrum
- P. Jalote, A. Palit, P. Kurien, and V. T. Peethamber,“Timeboxing: A Process Model for Iterative Software Development,” Journal of Systems and Software, vol. 70, no. 1–2, pp. 117–127, 2004, doi: 10.1016/S0164-1212(03)00010-4.
- Z. Racheva, M. Daneva, A. Herrmann, and R. J. Wieringa,“A Conceptual Model and Process for Client-Driven Agile Requirements Prioritization,” in Fourth International Conference on Research Challenges in Information Science (RCIS), IEEE, 2010, pp. 287–298. doi: 10.1109/RCIS.2010.5507388.
- M. Denne and J. Cleland-Huang,“The incremental funding method: data-driven software development,” IEEE Software, vol. 21, no. 3, pp. 39–47, May 2004, doi: 10.1109/MS.2004.1293071.
- D. Clegg and R. Barker,Case Method Fast-Track: A Rad Approach. Addison-Wesley Longman Publishing Co., Inc., 1994.
- DSDM Consortium,The DSDM Agile Project Framework. Dynamic Systems Development Method Limited, 2014. [Online]. Available: https://www.agilebusiness.org/wp-content/uploads/2026/05/DSDM-Agile-Project-Framework-Handbook.pdf
- E. Miranda,“Time boxing planning: buffered moscow rules,” ACM SIGSOFT Software Engineering Notes, vol. 36, no. 6, pp. 1–5, Nov. 2011, doi: 10.1145/2047414.2047428.
- J. Karlsson and K. Ryan,“A Cost-Value Approach for Prioritizing Requirements,” IEEE Software, vol. 14, no. 5, pp. 67–74, 1997, doi: 10.1109/52.605933.
- E. Miranda,“Planning and executing time-bound projects,” Computer, vol. 35, no. 3, pp. 73–79, Mar. 2002, doi: 10.1109/2.989933.
- M. Svahnberg, T. Gorschek, R. Feldt, R. Torkar, S. B. Saleem, and M. U. Shafique,“A Systematic Review on Strategic Release Planning Models,” Information and Software Technology, vol. 52, no. 3, pp. 237–248, 2010, doi: 10.1016/j.infsof.2009.11.006.
- E. Miranda,“Managing Software Development.” 2014.
Disclaimer: AI is used for text summarization, polishing and explaining. Authors have verified all facts and claims. In case of an error, feel free to file an issue.