Release Planning

While using agile methods, we advocate defining a vision for the project that will align everyone and help them focus on the right underlying concepts and point them towards a shared product vision. This product vision is championed by the product owner and defines the “right thing”. When done right, we don’t need to define the vision in great detail, because everyone on the team understands* what is being targeted. The high level plan is then: develop towards the goal – undertaking only what is needed to realize the goal state, but remaining flexible enough to tune our progress as we better understand convergence towards the PO’s vision.

The draw back to this comes in the form of a question I hear far too often: How will I know when we will be done? Planning a release is critical for most organizations. There are always many costs and impacts that will are borne by tangential or ancillary groups within and without the organizations actually doing the development. These must be both planned and budgeted and can’t be taken lightly. The failure of many projects can be traced purely to the inability to integrate them into an operational environment, which can’t be done without planning and scheduling.

So, how do we ensure success? Clearly, it is simple if we timebox the release. When we get close to the end of the timebox, we move the sprints from releaseable to release and ensure that whatever we have done is hardened enough to go into production. However, how do we do it when there is a minimum number of features that need to be complete in order to create a viable release? That is a great question!




* Quick test for your team – ask any two people for their 30 second understanding of the vision / goal for the project. If the two elevator pitches agree, your team is spot on and your PO has done their job well; if not …. my guess is that you will also have problems achieving “done” on the project.