Rita's Agile Process Chart

The Rita’s Agile Process Chart is a matrix illustrating agile project management. The book compares agile, plan-driven, and hybrid approaches to help readers understand both predictive and adaptive methods. It emphasizes that project managers should tailor their approach to each project’s needs, and that hybrid methods can be effective for certain projects.

Feasibility

In agile, teams usually stay the same over time, and projects come to them. This is different from plan-driven methods where a new team might be formed for each project.

When checking if a project is feasible, there are a few key steps:

• Business Case: This is about making sure the project makes sense financially and strategically. Management looks at things like cost-benefit analysis and return on investment to confirm the project will bring value to the organization and its stakeholders.
• Product and Project Vision: The team creates a simple, clear statement — called an “elevator pitch” — that quickly explains what the project is, what it aims to deliver, and why it’s valuable. Imagine explaining it in the time it takes for a short elevator ride.
• High-Level Features and Estimates: The team lists general features the product will need, along with rough estimates of costs and resources required. These descriptions are broad and help give a sense of what the project will involve.

Initiation

When starting a project, you can assume that feasibility studies and project selection are already done, just like in plan-driven projects. At this point, the team focuses on creating several important items:

• Project Charter: This is a high-level overview that outlines the project’s scope, requirements, risks, and other key features. The team also develops or adapts a team charter, which is a set of agreements on how team members will work together, communicate, and meet project needs.
• Personas: These are detailed profiles of the different types of stakeholders or users who will interact with the product. Creating personas helps the team understand requirements from various user perspectives. The team also identifies and contacts actual stakeholders.
• Product Backlog: This is a detailed list of all features needed for the product, expanding on the initial feature list from the feasibility stage. The backlog is continuously refined and broken down throughout the project. Features are grouped using rough size estimates, often called “bucket sizes” or “t-shirt sizes” (small, medium, large, etc.).
• Product Roadmap (or Story Map): This visual plan shows the order in which features will be built and delivered over time, usually in releases or increments.

Throughout all this, the product owner plays a key role in guiding the team’s work, while the project manager ensures that processes are followed and helps remove any obstacles the team faces.

Backlog Items and Stakeholders

Agile Release Planning

The release map (or product roadmap) and feature backlog created during project initiation are further detailed during release planning for the first product increment. After releasing the first increment, the team plans the next, continuing for as many releases as decided at the start. Planning happens iteratively throughout the project, reflecting the adaptive nature of agile.

Key activities during release planning include:

• Slicing features into smaller stories: These stories are estimated more precisely using tools like Planning Poker. Requirements are refined, and a clear “definition of done” is created for each story.
• Establishing team velocity: The team measures how much work they can complete in one iteration (e.g., two or three weeks) and, with the product owner’s help, selects which stories to complete in the first iteration.
• Gathering detailed requirements: This continues for each iteration, while the product owner continuously prioritizes the backlog, and the project manager supports the team by ensuring shared understanding and removing obstacles.

Iterations

In agile projects, monitoring and controlling happen continuously as the product is developed, though the terms aren’t always used. The team works in short iterations (usually 2-4 per release) until a product increment is ready for delivery.

Here’s how it typically works:

• Before each iteration starts, the team quickly finishes planning. Then, during the iteration, they build the selected stories while the project manager helps remove any obstacles.
• The team holds daily standup meetings—brief (about 15 minutes)—to share progress, plans, and any issues. Longer discussions happen afterward to keep the meeting quick.
• The team builds, tests, and completes stories to show the product to the customer in an iteration review, where feedback is gathered.
• The product owner supports the team by answering questions, prioritizing the backlog, and preparing stories for future iterations.
• After the review, the team addresses customer feedback and holds a retrospective to discuss what went well, what didn’t, and how to improve.

This cycle repeats until a minimally marketable product increment—one that meets the basic customer needs—is ready for release, even as work continues on future increments.

Closing

There is no appreciable difference between closing processes in adaptive and predictive environments. You can review this information in the Closing section on Rita’s Agile Process Chart. Essentially, the team obtains final approval of the last product increment to be released during the project, turns it over to the customer, and holds their final retrospective.

The project manager also makes sure all procurements have been closed and that all project artifacts are current and are archived as part of the organization's process assets.

Hybrid Project Management Environment

A hybrid project management environment combines plan-driven (predictive) and agile (adaptive) approaches in various ways. Examples include:

• Using plan-driven methods for well-defined requirements and agile methods for unclear ones (e.g., building a small building predictively, then iteratively constructing office spaces).
• Applying a mostly plan-driven approach but incorporating agile tools like electronic task boards and daily standups to improve communication, especially with remote teams.
• Developing a product adaptively (iteratively) and then implementing it predictively once approved (e.g., incrementally developing complex software, then rolling it out with plan-driven methods).