Even with many Scaled Agile frameworks, a number of courses on scaling Scrum teams, and many experienced professionals getting certified year after year, when I ask Scaled Agile practitioners to differentiate between the backlogs at a higher level to the lower team level and how it’s done, they fail. They can’t demonstrate. And I’ve asked many.

The reason is not hard to fathom. It’s not their fault. Rather, it’s due to a lack of practical applicability. In other words, they’ve not seen it in action or used any (good) software tool. Hence, there is no real understanding and internalization, except knowing some theoretical jargon here and there.

Scaling is complex, but it need not be hard to understand. As I write, the below age-old saying rings true:

I hear and I forget. I see and I remember. I do and I understand.

In this article, we will follow the above wisdom and learn by doing. We will learn by visualizing and applying, going from the Product Backlog to CIPSA Sprint Backlog, which will be executed by the whole team. Then we will also visualize and learn the individual Team Sprint Backlogs. Towards the end, we will see all of these backlogs fit together in action in a video demonstration.

So, let’s start with our current scenario.

Our Scrum at Scale Scenario

For our Scaled Scrum project, we have three Scrum teams working together on a single product backlog. The three individual Scrum teams have various usual roles such as Developers, Scrum Masters, and Product Owners. For the CIPSA team, however, we have two primary roles: Chief Product Owner (CPO) and Principal Scrum Master (PSM). This is shown in the below figure.

The CIPSA Team diagram. — The CIPSA Team

The CIPSA team encompasses all the individual Scrum teams and has the above additional two primary roles. The CIPSA team is shown in the bigger circle, whereas the individual Scrum teams are in smaller circles within the bigger one. Also note that both the CIPSA team and individual Scrum teams are in Sprint 1, i.e., the Sprints are synchronized.

Proceeding further, for our case, we are going to follow the CIPSA Scrum Framework. You can download the CIPSA Framework for free here.

Product Backlog to CIPSA Sprint Backlog to Team Sprint Backlog

The Product Backlog is for the entire CIPSA team. It’s a single backlog that has all the work items. The Product Backlog will have the Product Goal, and a refined backlog will be presented to the CIPSA team in the CIPSA Sprint Planning meta-event by the CPO.

In this CIPSA Sprint Planning meeting, the CIPSA team will create the CIPSA Sprint Backlog, which will have the CIPSA Sprint Goal.

After this meeting, the individual Scrum teams will work on the items assigned to them, break the items into individual tasks, and create the respective Team Backlogs. In other words, for every Scrum team, we will have an individual Team Sprint Backlog. As we have three Scrum teams, we will have three Team Sprint Backlogs:

Team A Sprint Backlog,
Team B Sprint Backlog, and
Team C Sprint Backlog.

For your visualization, it’s shown in the below figure.

Product Backlog to Team Backlog diagram. — Product Backlog to Team Backlog

As shown above, the Team Sprint Backlog is created from the CIPSA Sprint Backlog and the later one is created from the Product Backlog. The Team Sprint Backlog has the Team Sprint Goal, which is in alignment with the CIPSA Sprint Goal. The CIPSA Sprint Goal, on the other hand, is in alignment with the Product Goal.

At the end of every Sprint, an integrated increment is given, which is known as the CIPSA Integrated Increment. This Integrated Increment is the sum of all integrated work completed by the entire CIPSA team. And with every Sprint, the CIPSA team is moving closer towards the Product Goal.

The Prioritized Product Backlog

As mentioned earlier, we have a single Product Backlog and the CIPSA team is going to deliver a large, complex Stock Trading system catering to millions of users, customers, and paid subscribers. When put into MS Project Agile, the Product Backlog comes as shown below. At this stage, we have an unrefined backlog.

Also note that we have not associated teams with the backlog items. As the CIPSA team completes the Cross-Team Backlog Refinement session, the items will be ordered, and the entire team will have a forward-looking plan for the next two or three Sprints. After our backlog refinement, we have the following Product Backlog shown again in the Sprint Planning sheet view.

As shown above, the items are now reordered. The teams and Sprints are now associated with the backlog items. For example:

“Login to the trading system” is associated with Team A, whereas “Create a new user” and “Buy a stock” are associated with Team B and C, respectively.
All three teams are also associated with the upcoming Sprint, i.e., Sprint 1.
Similarly, some of the items are associated with Sprint 2 and Sprint 3. Such planning is known as rolling wave planning in Agile.

This can also be seen in the Sprint Planning Board view as shown below.

After reordering the items, one can drag and drop items into the respective Sprints in the Sprint Planning Board, which is for the entire CIPSA team.

The CIPSA Sprint Backlog

Next, we are going to build the CIPSA Sprint Backlog. The CIPSA Sprint Backlog will have the following meta-events.

CIPSA Sprint Planning,
CIPSA Daily Scrum,
CIPSA Sprint Review, and
CIPSA Sprint Retrospective.

These meta-events will be conducted in the Sprint 1 for the entire team. Hence, we will use the respective naming conventions. For Sprint 1:

the planning meta-event will be “CIPSA Sprint 1 Planning,”
the daily stand-ups will be “CIPSA Daily Scrum (Sprint 1) 1,” “CIPSA Daily Scrum (Sprint 1) 2” and so on,
the review meta-event will be “CIPSA Sprint 1 Review,” and
the retro meta-event will be “CIPSA Sprint 1 Retrospective.”

The naming convention is quite important to understand as we will run with multiple Sprints – possibly hundreds of them. You’ve to give clear naming conventions to differentiate between teams and Sprints. Otherwise, with multiple Sprints and multiple Scrum teams, it’s easy to get lost in the plan!

After we have the meta-events added, the first version of the CIPSA Sprint Backlog (specifically, the CIPSA Sprint 1 Backlog) is shown below.

Let’s interpret the above figure shown in the Gantt Chart. A similar one will be available in the Sprint Planning Sheet view. As shown:

The first meta-event is the CIPSA Sprint 1 Planning. It’s a line item.
The next one is CIPSA Daily Scrum for Sprint 1 and it’s a recurring item.
The last two meta-events are CIPSA Sprint 1 Review and CIPSA Sprint 1 Retrospective. Both are line items.
While the CIPSA Sprint Backlog related items are associated with “All Team,” the individual Scrum team items are associated with the respective teams.

All these items related to the CIPSA Sprint 1 Backlog are highlighted in blue. Again, do note the naming conventions.

The Team Sprint Backlog

Next, we will proceed to create the Team Sprint Backlogs for all the Scrum teams. In this case and per the CIPSA Scrum Framework, we will have the following events:

Team Sprint Planning,
Daily Scrums for individual teams, and
Team Sprint Retrospective.

Do note the CIPSA Sprint Review replaces the individual Team Sprint Review, because our focus is on the CIPSA Integrated Increment, not the individual Team Increments.

These individual team events will be conducted in the Sprint 1 for the respective Scrum teams. Hence, we will use the respective naming conventions. For Sprint 1:

the planning event for Team A will be “Team A Sprint 1 Planning,”
the daily stand-ups will be “Team A Daily Scrum (Sprint 1) 1,” “Team A Daily Scrum (Sprint 1) 2” and so on, and
the retro event will be “Team A Sprint 1 Retrospective.”

Here too, the naming convention is quite important to understand and use.

Once we have these events, the first-cut of the Team Sprint Backlogs will be prepared. The figure shown below is for Scrum Team A.

As you can visualize in the above figure, for Team A:

The first event is the Team A Sprint 1 Planning. It’s a line item.
The next one is Team A Daily Scrum for Sprint 1 and it’s a recurring item.
The last event is Team A Sprint 1 Retrospective and it’s a line item.

Next, we will take the work items from the Product Backlog for Team A and break it down to individual tasks. While the feature items can be in story points or in any other estimation, the tasks will be estimated in hours.

For the “Login to the trading system” feature for Team A, we will have the following tasks:

Design and develop
Implement UI
Prepare test plans
Execute test plans
Integration Work
PO Review.

Do note that the Team Increment can come anytime during the Sprint 1, but it has to be integrated into the main branch (or line) in order to have the CIPSA Integrated Increment at the end of the Sprint.

After we have these tasks items, the Team A Sprint 1 Backlog will look like the one shown below.

As shown above, the Team A Sprint 1 Backlog encompasses all the items, including the events, which will be executed or conducted in Sprint 1. Similarly, we will have two more Team Backlogs – Team B Sprint 1 Backlog and Team C Sprint 1 Backlog.

Demonstration – Backlog Management at Scale

Now, it’s a good time to see what we have learned so far with the help of the MS Project Agile software tool. To support this, I’ve prepared the following video [duration: 6m approx.], the content of which is taken from the newly launched Certified In Practical Scaled Agile (CIPSA) course. For the best experience, you may want to go full-screen with HD mode and plug-in your earphones.

Exercise – Comparison of the Backlogs

We have understood how these Backlogs are prepared and we also looked at them practically. Next, ask yourself, what are the differences among these backlogs? Below are the five areas – creation of the artifacts, goal associations, the content inside followed by the life cycle of the artifact and events. In these areas, you can attempt to list out the differences.

Table - Differences in Backlogs — Table – Differences in Backlogs

The answer is explained in the below video [duration: 5m approx.]. While watching the videos, bring out your pencil and paper to learn better.

Conclusion

Slightly modifying the initial quote we started with, a related one is the following:

Tell me and I forget, teach me and I may remember, involve me and I learn.

Indeed, we learn by doing. Because that is when we get truly involved.

There are connections among our fingers, hands, and brains. When we do it with our own hands and our fingers are involved, coordination happens among our fingers, eyes, and brains.

Visuals like figures and comparison tables coupled with practical, hands-on applicability are powerful. With these, we quickly grasp the explained concepts. And as we do it ourselves, it registers in our minds and memories for a long time.

With this article, you now understand how to manage the backlog items taken from a cross-team refined Product Backlog, and build the CIPSA Sprint Backlog and multiple Team Sprint Backlogs.

References

[1] NEW Certification Course: Certified In Practical Scaled Agile (CIPSA), by Satya Narayan Dash

[2] Scrum at Scale: Multiple Teams and Synchronized Scaled Sprints with MS Project Agile, published by MPUG.com

[3] Scrum and Microsoft Project: Agile Project Management Training, hosted at MPUG.com

Elevate your project management skills and propel your career forward with an MPUG Membership. Gain access to 500+ hours of PMI-accredited training, live events, and a vibrant online community. Watch a free lesson and see how MPUG can teach you to Master Projects for Unlimited Growth. JOIN NOW