Traditional project planning techniques rely on a comprehensive, detailed and stable requirements specification as a prerequisite for creating a project plan. This approach is not only error-prone when dealing with innovative and complex products. It is also difficult to employ in an agile context, as not all requirements are known upfront and changing requirements are welcomed – rather than treated as an unwanted exception. This article describes an alternative project planning approach that flexes requirements but fixes time.
The Iron Triangle
Project planning – often called release planning in an agile context – guides the development of a successful product. It starts with making a decision about which project lever—time, cost, or functionality—cannot be compromised to launch a successful product. Is adherence to the launch date mandatory? Is the development budget fixed? Or do all product requirements in the product backlog have to be delivered? These three levers are also referred to as the “iron triangle.” Fixing time, budget, and functionality is not possible; at least one has to act as a release valve. Note that quality is fixed in an agile context and must not be compromised. In Scrum, the quality criteria every product increment must fulfill are captured in the definition of done.
Why Fixing Functionality is Bad
Fixing functionality is a bad idea on an agile project. Even with a shared product vision in place, the product’s exact properties, its functionality and features, are not all known up front but are instead discovered based on customer and user feedback. Requirements emerge and the product backlog evolves as the team learns more about customer needs and how to meet them. Trying to fix functionality severely damages the team’s ability to adapt the product to the customer’s response. It is likely to result in a poor product—and not a product that customers love.
Identifying the Window of Opportunity
Instead, I recommend fixing the time and flexing functionality. Identifying the launch date is facilitated by the product vision, which acts as the shared overarching project goal. It sketches the future product and describes its target customers and users together with the essential functionality provide. The vision allows us to determine the window of opportunity, the time frame in which the product must be launched to achieve the desired benefits. Fixing the window of opportunity protects time as the scarcest resource. If the date is missed, the opportunity is gone, and launching the product no longer makes sense. Note that choosing a launch date based on the work in the product backlog is difficult, as it forces the team to freeze requirements at an early stage. It often also results in a poor estimate. In fact, an estimated launch date based on requirements may be off by as much as 60 to 160%; a project expected to take 10 months could take anywhere from six to 16 months. This well-known correlation is called the Cone of Uncertainty. Identifying the window of opportunity rather than trying to estimate a probable launch date avoids these issues.
Creating a Steady Innovation Cadence
Fixing the date provides the opportunity to create a steady innovation cadence. This is achieved by choosing the same timebox for all releases. Sound crazy? Well, that’s what Salesfore.com, a leading provider of on-demand customer relationship management services, did—with quite some success. After years of rapid growth, Salesforce.com found itself in a difficult situation in 2006. Its ability to release new products had decreased to only one per year, and productivity had sharply declined. In an effort to turn around its fortunes, the company introduced Scrum. Since then, Salesforce.com has followed a strict four-month innovation cadence. The results are stunning. Salesforce.com experienced an amazing increase in the number of features delivered by establishing short, steady release cycles. At the same time, the company drastically reduced its lead time for new functionality.
Determining the Budget
Fixing the date and using stable Scrum teams make determining a budget straightforward—assuming that labor is the decisive cost factor. If you have to scale your project, accurately forecasting the budget is more difficult, particularly for new-product development projects. If the budget is in danger of getting overrun, the product owner has to make a choice: Either ship with less functionality, or increase cost by asking more people to join the project—as long as there is enough time for the new project members to increase productivity. Apple, for instance, decided to increase cost and added more people to its first iPhone project in order to stick to the release date. But beware of Brooks’ Law: “Adding manpower to a late software project makes it later.”
What about Fixed-Price Contracts?
If you have a choice, avoid projects with fixed price and fixed scope. If that’s not possible, try the following: Split a fixed-price contract into two parts and carry out two consecutive projects. The first project creates the product vision and partly implements the vision using two to three sprints. At the end of the project, the product backlog has evolved based on customer feedback. This enables you to create a realistic release plan and to come up with a realistic budget estimate for the second project, which continues to bring the product to life.
Summary
Fixing time and flexing functionality facilitates the emergence of requirements and helps create a steady innovation cadence. It frees agile teams from having to describe most product backlog items in detail at an early stage, and it avoids the difficulty of deriving a realistic project end date from the requirements. Find out more about release planning on agile projects in my new book Agile Product Management with Scrum: Creating Products that Customers Love. The book is the product owner’s guide to creating successful products with Scrum; it discusses the product owner role together with essential product owner practises increasing envisioning the product, grooming the product backlog and planning the release.
