Organizations rooted in traditional project management often fail to reap the benefits of Agile. This is primarily because they try to implement Agile approaches in ways that align with traditional project management biases.  One of the most common examples of this corruption of Agile practices is developing project schedules that attempt to fix the constraints of the Iron Triangle:  Schedule, Scope, and Budget / Resources.

In this article, I explain why project roadmaps are a much better fit for Agile projects than traditional project schedules.

Traditional Project Schedules

Obviously, all projects have a beginning and an end.  How much time transpires in between depends on how long it takes to accomplish a certain amount of work based on some amount of resources (e.g., equipment, people).  The total cost of the project depends on the per hour cost of all those resources and the number of hours they contribute to the project.

Traditional projects attempt to fix or set the constraints of the Iron Triangle from the start.  This entails identifying all of the work that needs to be done, estimating how long each item of work will take, and identifying who will do the work and at what rate.  Planners determine the project’s budget from these data.  To keep schedule, cost, and scope as close to the original plan as possible, project management works mightily to minimize changes to planned project scope (i.e., minimize “scope creep”).  The traditional project management artifact that ties all three constraints together is the project schedule, often referred to in larger traditional projects as the Integrated Master Schedule (IMS).

Thus, in traditional software projects, planners develop schedules not just to set expectations of when teams will deliver and release software functionality, but also to track:

• Work task progress
• Dependencies between tasks
• Estimated schedule impacts of early / late task starts and completions
• Costs incurred as well as estimated future costs

The project schedule is the main instrument of traditional project management control.  Project managers depend on it to manage tradeoffs between Iron Triangle constraints as the project progresses.

Project Critical Path

As I discussed in the previous section, traditional project managers use project schedules to track dependencies between work tasks.  This allows them to track how the actual start and completion dates of any given work task will impact subsequent tasks.  It is important to stress, however, that these schedule impacts are based on estimates that may (likely) be inaccurate.

The longest sequence or path of consecutive schedule activities is known as the project’s critical path.  Usually, the critical path is the path that determines duration of the project.  Tracking a project’s critical path is important in traditional project management because task delays along the critical path impact project schedule more than those not on the critical path.

Agile Projects Break the Iron Triangle

Unlike traditional projects, we manage Agile projects primarily by managing scope.  Agile projects hold budget and schedule milestones fixed while managing scope to fit available time and resources throughout the project.  This approach to planning aligns with Agile’s principle of welcoming “changing requirements, even late in development.”  Rather than defining the total scope of the project upfront, we define it as we go.  To pull this off without going over budget or schedule, Agile teams employ timeboxing, sizing, ordering, and frequent delivery of business / mission capabilities.

Timeboxing

Agile planning breaks up the project planning horizon into short time periods or “timeboxes” throughout the project timeline.  Instead of creating a plan and schedule for the entire duration of a project, teams break up planning across each and every timebox on the project timeline.  Agilists usually call these timeboxes “sprints” or “iterations.”

Sizing

Agile teams plan enough work to fill the timeboxes. They don’t change timebox duration to fit the work.  They do so by estimating the “size” of the business or mission features / functionality they plan to build.  The size of a given feature (or user story) represents the combination of perceived or estimated:

• Feature complexity, risk, and uncertainty
• Level of effort required to complete the feature

Teams estimate features by “sizing” them relative to each other.  More complex features typically require more time and effort to complete, thus making them relatively “bigger” than less complex features.

Based on these “sizes”, and the team’s record of finishing different sized features during previous timeboxes (known in Scrum as “velocity”), Agile teams determine which features to break down into smaller ones and which will fit into the next timebox or two.

Ordering

Rather than following a detailed and static plan of component deliveries for later integration, Agile teams plan their work based on adaptive planning. Ordering the development, delivery, and release of features / deliverables takes into account both what is most important or valuable from a business / mission perspective and the technical dependencies between the items. I cover ordering, and how it differs from prioritization, here.

Frequent Deliveries

Agile teams deliver small increments of valuable business or mission functionality.  Each increment builds on previous ones.  The system grows and evolves an increment at a time.  Every delivery contains working functionality that is potentially releasable.  This means that the functionality is ready for deployment and release when authorized.

Agile teams avoid delivering individual components.  They strive to deliver fully functional features.  Doing so allows project sponsors, stakeholders, customers, and end users to validate that teams delivered the right things.

The faster and more often teams deliver, the more opportunities exist to validate the solution as it grows and evolves.  This Agile “empiricism” provides teams the information they need to plan, not just the next timebox or two, but the direction of the solution / product and its development.

At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly.

https://agilemanifesto.org/principles.html

No Critical Paths in Agile Projects

Since teams define and refine the project plan continually throughout the project, there is no predefined set of work tasks to form a critical path.  Also, in the case of Scrum, for example, teams organize work around implementation of user stories, not accomplishment of developer tasks.  Rather than focusing on tracking task completion (as traditional project management does), Agile teams track delivered features. 

Working software is the primary measure of progress.

https://agilemanifesto.org/principles.html

So, if traditional schedules don’t align to Agile projects, what should we use instead?

The Project Roadmap

Project roadmaps afford teams and project stakeholders the flexibility to shape the evolution of solutions throughout development.  Instead of following and tracking a detailed predictive plan via a project schedule, Agile projects can leverage project roadmaps to chart the course of development.  The course charted is informed by ongoing verification and validation of potentially releasable and released functionality throughout development.

A project roadmap should depict the delivery of business or mission capabilities at a coarse-grained level.  In the case of Scrum, for example, I recommend keeping the project roadmap at the epic level.  The idea here is not to track every feature / user story and all of their associated tasks.  Instead, the project roadmap should present the major slices of system functionality that deliver complete business or mission utility. However, some development team collaboration tools offer features that make drilling down below the epic level on the roadmap easy.

As depicted in Figure 5, we arrange the epics along a timeline that depicts their estimated start and end dates.  Teams arrange the epics in the order they expect to work them, taking into account business / mission priorities and technical dependencies between them.

Finally, we include major milestones and deadlines that teams must meet as part of project activities.  Since Agile teams separate deployments to production from releases, and every timebox offers an opportunity to release, there is no need to clutter up the roadmap with lower-level details.

Conclusion

Project roadmaps are a better way of tracking planned completion and release of business / mission capabilities by Agile teams than traditional project schedules.  They align with Agile scope management principles and provide the planning flexibility necessary for Agile projects.  They are also much more lightweight and easier to maintain than complex project schedules.  Most important, leveraging project roadmaps helps us avoid the tendency to over-plan and over-analyze that often turns Agile projects into traditional project management efforts.

Last Updated on March 2, 2022