Determining the launch date and the budget before development starts can be tricky in Scrum. Relying solely on Scrum’s empirical approach, a team working on a new product has to carry out at least one sprint to measure the velocity and to understand the rate of change in the product backlog. For many organisations this is difficult to accept, as an investment decision is often required before the development work can start.
Frozen Requirements or No Informed Investment Decision?
Employing a traditional planning approach and trying to capture all requirements in detail upfront in the product backlog is not only error-prone when dealing with innovative products. It is also undesirable in an agile context where the product’s detailed functionality is discovered during the development through early and frequent customer and user feedback.
Does this mean that we cannot make an informed investment decision at an early point in time on an agile project? Luckily, the answer is no. This blog post discusses how we can determine the launch date and the project budget before the first sprint – without turning the product backlog into a disguised requirements specification.
Running the Release Planning Workshop
A collaborative workshop involving the right people is a great way to carry out the initial release planning: The product owner, the ScrumMaster, the team, and stakeholder representatives including a management sponsor or the customer should attend the workshop. A shared product vision and an initial product backlog now have to be in place. The former paints a rough picture of the future product, scopes the project, and acts as the shared overarching goal. The latter sketches the outstanding work necessary to develop the product. Make sure all attendees understand and buy-into the vision.
Step 1: Identify the Window of Opportunity
Based on the product vision and the backlog, we determine the window of opportunity, the time frame in which the product must be launched to achieve the desired benefits. If the date is missed, the opportunity is gone, and launching the product no longer makes sense. The work carried out to create the vision helps us identify the window of opportunity and understand if the product can be developed and launched within the window selected; we leverage the insights gained from the initial market research and technical exploration work. The beauty of this approach is that it does not require having all requirements described in detail in the product backlog. But it assumes is that the vision stays stable for the duration of the development effort.
Step 2: Determine the Budget
Once the window of opportunity and a delivery date have been identified, we can determine the budget. To do so, we ask ourselves who is required to work on the project, which skills are needed and how many teams may be required. We then add additional items such as licensees for tools and third-party software. This provides us with an initial budget.
Step 3: Make a Go/No-go Decision
Understanding the timeframe and the budget and having the sponsor or customer present, should allow us to make a go/no-go decision in the release planning workshop, and in the latter case to discuss if and how the vision and the product backlog should be adapted. Making a decision in the workshop does not only create transparency and leverage the input of the attendees. It also avoids waiting and delays and helps reduce time-to-market.
Once development is underway, we capture the progress at the end of each sprint in form of a release burndown chart and create a forecast for the reminder of the project. This validates the original plan. It allows the product owner to steer the project and to trade off time, budget and functionality. Note that quality is frozen in an agile context and must not be compromised. Quality compromises result in defective product increments, making it impossible to clearly see the progress and to release software early and frequently.
Using a collaborative release planning workshop and determining the window of opportunity facilitates an early investment decision and the emergence of requirements. It frees agile teams from having to describe most product backlog items in detail at an early stage, and it avoids having to carry out one or more sprints before a date and a budget can be established.