Rapid Product Development Projects Using A Hybrid Agile/Waterfall Framework

Rapid Product Development Projects Using a Hybrid Agile/Waterfall Framework

Agile is a useful project management method that can be used within a New Product Development (NPD) process to accelerate certain stages of product development. The Agile framework for incremental product development uses one or more cross-functional teams, responsible for creating and adapting their processes within 3-week Agile Sprints.

Agile is built on the concept of breaking down the project schedule into smaller, more manageable work components. This is effective for longer projects or projects where not all the design elements of the product are clear. Projects that require innovative approaches to realize the final product design will often benefit from an agile approach to their development.

The Opportunity to Combine Frameworks for Better Planning

The Waterfall approach to project planning works well when the underlying mechanisms of the project are reasonably understood. As well, when there is employee turnover, waterfall’s strong documentation allows for minimal project impact. Some project deliverables lend themselves well to the Waterfall approach. For example, training, marketing, identifying customer requirements and research. They are usually time-bound and follow a relative linear path of work.

The Hybrid Waterfall/Agile framework combines the power of waterfall with the flexibility of Agile to accelerate the management of new product development projects.

A Hybrid Agile Framework

1. Identify the Key Agile Roles

Product Owner

  • Can be the Project Manager and/or Product Manager
  • Responsible for product success in the marketplace
  • Prioritizes product features
  • Link between all customers and other stakeholders and the Sprint Team(s).
  • Responsible for deciding which product requirements and features are actually implemented
  • Ensures that the decisions regarding which of the features to develop, occur at the beginning of each iteration, when the Sprint Team is planning their work

Scrum Master (can be the Project Manager)

  • Can be the Project Manager, if familiar with the Agile process.
  • Ensures everyone works with established timebox (time allotted for meetings, decisions and so on)
  •  Leads all Sprint Meetings
  • Needs to know when to get involved and when to step back in the team
  • Has no authority over the team and its decisions

Sprint Team Members

  • Estimates the work required to deliver the features and the tasks to be done to complete the required work.
  • Adheres to a common goal and establishes rules (norms) for how the team will work effectively together (their behaviours).
  • Develops and tests the product and delivers the product features.
  • Ideally includes no more than 7 individuals including the Product Owner and Scrum Master (larger teams have difficulty in rapid decision making).

2. Create the Work Breakdown Structure

  • Create a detailed Work Breakdown Structure (WBS), using the Waterfall method, for the entire project.  Deliverables that will considered for Agile will usually be developed at a higher level of granularity and with longer task durations.
  • The Agile user stories (step 6) will be created that correlate these WBS tasks.
  • The Product Backlog (step 10) will be created from the WBS output of this session.

3. Select Project Deliverables and/or tasks to use in Agile

  • Review the entire program plan and identify a deliverable and/or series of Level 2’s and 3’s.
  • Determine what to use through Agile by considering the end result or outcome.  For example, will it result in a prototype or major feature?  This indicates that the deliverable and related activities and tasks will be suitable to take through the Agile Process.
  • The total amount of time to complete should be at least 2 months but no more than 6 months.

4. Organize an Agile Release Planning Meeting

This meeting will be time-boxed for up to 1 day.  It includes the Project Manager, Product Owner, customers and/or internal employees who understand the customer’s requirements and subject matter experts (likely be the same individuals selected to join one of the sprint teams, organized after this meeting.)  During this Agile Release Planning Meeting the team will create the product vision, user stories and product backlog.

5. Create the Product Vision

Similar to the Project Scope’s Goal but specific to the product feature(s) or services to be developed through the Agile process.  The intent is to create and agree on a vision for the work to be undertaken in a 2 to 6 month “timebox.”  The entire project might be for 2 to 3 years but each Agile process should be for no more than 6 months.

6.  Create User Stories

The process starts by defining the roles of who will use the product.  User stories are then created from the groups of tasks taken from the project plan.  The stories will produce the product feature(s).  The project plan tasks are re-written as a story, wish-list item and/or business/customer requirement.  For example, a group of Level 3”s, when completed, will deliver “x”.

User stories will populate the Product Backlog.  Bigger stories (i.e., stories that are too big for a sprint) are called “Epics.”  They will get broken down into smaller stories when the Sprint Backlog is created.

7.  Calculate Business Value

The team will describe three to five drivers for the entire group of stories. These will identify the Business Value (driven by the Vision).  The Business Value helps clarify how the vision will be measured.  Measurements include outcomes.  That is, when the product is fully released, these measures (in business value) will answer the question, “How will we know that we’ve met the customer and business requirements?”

8.  Calculate Effort

Within Agile we compare all the User Stories to each other.  This measures the relative effort of one story to another.  The smallest story will be given an effort of “1.”  A larger story might have an effort of “20.”  This is not a measurement of time or resources.  It is a measure of relative effort of one story to another.

9. Calculate Return on Investment

  • The Return on Investment (ROI) calculation identifies the order the stories should be executed through he team sprints. It is calculated as: Return on Investment (ROI) = Business Value/Effort
  • The Product Backlog will be created from this ROI number.
  • Once all of the stories have an ROI number, the team organizes/orders the stories on the basis of its ROI number.  The highest ROI number story will be the first and the lowest will be the last.

10. Create the Product Backlog

The Product Backlog is the master list of all work to be done in the entire Agile process.  Essentially it is a list of all the things needed to be done – the “what” is to be built.   The final order of the stories, based on their ROI factor, is used to create the Product Backlog.
It is a living document that can be changed throughout the entire Agile process. New requirements can be added and existing requirements may be modified, defined in more detail or deleted. As well, the priority of the stories can be changed. This is common as sprints are completed and new information is brought forward.

11.  Organize the Sprint Meetings

Sprint meetings are held to manage all of the items identified in the product backlog. These 3-week meetings will last over the full two to six month time frame agreed to for the product feature(s) or services to be developed through the Agile process.  There are a number of elements required for success:

  • The creation of a Sprint Goal for each 3-week Sprint.
  • The creation of the Sprint Product Backlog for each Sprint (items taken from the Product Backlog).
  • The identification of the Sprint Tasks from the Sprint Product Backlog to be managed each day within the 3-week Sprint period.
  • The development of the Sprint Task Board, which identifies the work to be done each day, within the Sprint.

12. Hold Daily Scrum Meetings

These are daily stand-up meetings held at the beginning of each day, at least three times per week, during each Sprint.  They are held for 10 to 15 minutes.  The daily scrum meeting is a debrief of what the team has done, will do, and their impediments.

13. Create a Sprint Burnout Chart

  • This chart is created by the Sprint Team after they’ve created their Sprint Backlog.  It indicates the total remaining team task hours within one Sprint.
  • The burnout rate is calculated each day by measuring the hours remaining from the hours originally estimated.  This is plotted on the Burnout Chart.
  • The Burndown Chart provides information about the current performance (burn down rate), which helps the team determine if the Sprint Goal can be reached in time, or if the team has to find additional measures to speed-up completion of the remaining activities.

14. Schedule the Sprint Review and Demo Meeting

The Sprint Review Meeting is held on the last day of each 3-week Sprint. The goal is to inspect and adapt the product that is being built. The team will demonstrates their deliverables/working product features to the Product Owner and relevant stakeholders. This demo is done as a live demonstration of the product features completed, not a report.

15. Hold a Sprint Retrospective Meeting

This meeting is held after the Sprint Review Meeting. The focus of the Sprint Retrospective Meeting is on how the team managed itself. The team assesses their effectiveness in working together throughout the Sprint and discusses what improvements can be made during the next Sprint.

16. Hold a Backlog Refinement Meeting

After a couple of Sprints it is usually apparent that the Product Backlog items need refinement because they are too large and/or poorly understood. In a Backlog Refinement Meeting (sometimes referred to as “Grooming the Backlog”) the Sprint Team(s) estimates the amount of effort required to complete the remaining Product Backlog items and provides other technical information to help the Product Owner prioritize them. This meeting is really a Pre-Sprint planning meeting. The stories for the next sprint are agreed-upon.

17. Complete the Product/Release Burn Down Chart

  • The Product Burn Down chart is an essential part of any agile project and is a way for the team to clearly see what is happening and how progress is being made from one sprint to the next.  It is created after each sprint.
  • It shows monthly (per sprint) progress towards the Product Vision and tracks the remaining Product Backlog effort from one Sprint to the next.
  • The chart provides information about current performance (burn down rate) which helps the team determine if Product Vision can be reached or if additional measures have to be identified to speed-up completion of the remaining stories and activities.


When a process is too complicated for a defined Waterfall method, it is more effective to use a hybrid approach which combines the Waterfall and Agile framework. The hybrid approach provides a number of benefits:

  • Ability to manage changing customer, sponsor and other project priorities
  • Increased collaboration with customers to support a market-driven approach
  • Reduced cost of failure figures by finding defects earlier in the development cycle through automated testing
  • Continuous improvement in team development. The team continuously reflects on how to become more effective, then tunes and adjusts their behaviour accordingly.



Michael Stanleigh

Michael Stanleigh, CMC, CSP, CSM is the CEO of Business Improvement Architects. He works with leaders and their teams around the world to improve organizational performance by helping them to define their strategic direction, increase leadership performance, create cultures that drive innovation and improve project and quality management. Michael’s experience spans public and private sector organizations in over 20 different countries. He also delivers presentations to businesses and conferences throughout the world. In addition to his consulting practice and global speaking he has been featured and published in over 500 different magazines and industry publications.

For more information about this article you may contact Michael Stanleigh at mstanleigh@bia.ca