ALM Rangers switching to single TPC/TP and multiple Teams model … Part 2

In ALM Rangers switching to single TPC/TP and multiple Teams model we spoke about possibly changing to a single Team Project model, which lead me to consider the following designs:

Our previous view

Proposed Team Project Design - v1	In essence we are thinking of creating a single Team Project for all related projects. As shown in the illustration we would create one Team Project “VisualStudioALM” which consolidates all of the projects relating to Visual Studio ALM. The Core Team would be the likes of Brian Blackman, Bijan and I, who need to have an overview of how we are doing from a 10,000m view.
Proposed Iteration Design - v1	The iterations would be split into various projects, each containing the releases and sprints as per the default setup. I am still pondering whether we need a node above the projects.

Our revised view

What followed were some really great discussions with the master of Teams …”Gregg” and Brian Blackman.

I am capturing my understanding of these discussions in this blog post, so that we can share our thoughts, evolve it until it is near perfect and ready to use as a recipe for the next wave of ALM Ranger projects.

Proposed Team Project Design – v2

The TPC and TP model looks the same, except that we changed Core Team to Default Team. Our thoughts: Use the default team for the core team that will support and guide the rest of the teams. Have a single Team Project for all projects that are related to a pillar of technology. This means that all Ranger projects related to Visual Studio will reside in a single Team Project, named VisualStudioALM in the illustration.

Proposed Iteration Design – v2

The iteration hierarchy looks a lot different. We have a series of shared sprints with the same duration, for example 1 month, shown as Sprint 1 and 2. Optionally the sprints can be sub-divided for teams that prefer a shorter shorter sprint durations, for example 2 weeks, shown as Sprint 2.1 and 2.2.

Summarizing our thoughts in a picture

The following illustration summarizes our thoughts to date:

1. The Team Project VisualStudioALM is the container for all projects and teams targeting Visual Studio ALM.

2. The projects X and Y are isolated at Team level.

3. The projects within VisualStudioALM share a common set of iterations (sprints) and thus a common cadence of either 4-week or 2-week blocks.

   IMPORTANT: One important impact of this change is that all teams start and stop together and there is no more extending iterations (sprints). This requires better planning by the team lead and more control over what is put on the backlog. And in those cases where too much work has been taken on during an iteration (sprint) the process will be to put the task related work item(s) back on the Product Backlog, for selection in subsequent iteration (spring) planning meetings.

4. The iterations (sprints) are grouped by the financial year, starting with iteration (sprint) 1 on July 1st.

5. Project X runs with a 4-week cadence and starts on September 1st. The team’s first iteration (sprint) is therefore #3.

6. Project Y runs with a 2-week cadence and starts on July 1st. The team’s first iteration (sprint) is therefore #1.1.

7. The Team Project VisualStudioALM has one master backlog in which we plan and queue backlog items not yet assigned to teams.

8. Projects X and Y have their own backlogs, to define and manage the scope of each project.

9. Projects X and Y will view their current iteration (sprint) tasks on boards  specific to each project and scoped to the iteration (sprint) nodes.
   … example of iteration configuration for Project X team.
     … example of current board for Project X.

10. The core (default) team can have an aggregated view of all tasks for all projects on one board scoped to the FYnn node.
    … example of iteration configuration for Core Team.
    … example of aggregated board for all projects viewed by core team.

What do you think?