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