Agile Central - what determines Exit Agreement criteria propagating up and down project hierarchies
Article ID: 126188
Updated On:
Products
CA Agile Central On Premise (Rally)
CA Agile Central SaaS (Rally)
Issue/Introduction
We are observing two seemingly opposite behaviors with Exit Agreements. We would like to know why these two behaviors.
1. In a Kanban Board for user stories:
The Exit Agreements are not being copied to similar kanban boards of parent or children projects. So, if editing the Exit Agreements to any Flow State then it seems to be private to the board where it is created. It will not be copied to boards of others projects.
2. In the Portfolio Kanban Board for features and portfolio items:
The Exit Agreements are being copied both up and down the project hierarchy. Further, if the Exit Agreements are added to a custom portfolio kanban board then they are copied also to the 'standard' Portfolio Kanban page too.
These two behaviors seem to be opposite of each other. What is the reason for it?
Environment
Release:
Component: ACSAAS
Component: ACSAAS
Resolution
Indeed the two behaviors described here are different, seemingly opposite. Yet, they are designed to reflect the Agile methodology and Rally concepts.
First, we need to understand that Exit Agreement 'belongs' to the Flow State. It does not belong to the individual items (whether portfolio or story items). They define the acceptable criteria in-and-out of the flow states.
There is a substantial difference between portfolio items (including features) and user stories. Portfolio items are considered high enough in the business hierarchy. Despite that each portfolio item is assigned to a specific project, they are not considered 'private' to that project. Often they are being examined in a multi-project context. The Exit Agreements on portfolio items normally reflect acceptance criteria that applies in many or all projects.
This is not the case with user stories. User stories are considered low-level objects and they are considered 'private' to the project. They are assigned a project and normally they will not be even examined in the context of other projects (even children projects). The user stories are considered to belong to the team they're assigned to.
Therefore, the two behaviors expressed in this question are a good reflection of these concepts:
- There is no reason to allow copying exit agreements for user stories from one project to another, from one team to another since teams work differently.
In fact, different team may, and usually do, have different Kanban Boards altogether, with different flow states and different criteria to control that flow, for which they will need different exit agreements. You should take a note that the Flow States in the Kanban Board are can be customized and redefined in any project.
- Portfolio Kanban Boards are built to provide a higher-up business outlook where decisions usually take into consideration more than a single team and more than a single project. You may note that you can not customize or redefine the states of the Portfolio Kanban Board. These states are static across all projects to streamline them for the decision makers. By this same consideration, so go the exit agreements, that are part of these states. Changing the exit criteria to a state is not considered a change 'for the project' or even within the 'confines of a project'. It is considered a change to the state itself which is across projects and hence the exit agreement change will be reflected in similar portfolio item kanban boards for all projects.
First, we need to understand that Exit Agreement 'belongs' to the Flow State. It does not belong to the individual items (whether portfolio or story items). They define the acceptable criteria in-and-out of the flow states.
There is a substantial difference between portfolio items (including features) and user stories. Portfolio items are considered high enough in the business hierarchy. Despite that each portfolio item is assigned to a specific project, they are not considered 'private' to that project. Often they are being examined in a multi-project context. The Exit Agreements on portfolio items normally reflect acceptance criteria that applies in many or all projects.
This is not the case with user stories. User stories are considered low-level objects and they are considered 'private' to the project. They are assigned a project and normally they will not be even examined in the context of other projects (even children projects). The user stories are considered to belong to the team they're assigned to.
Therefore, the two behaviors expressed in this question are a good reflection of these concepts:
- There is no reason to allow copying exit agreements for user stories from one project to another, from one team to another since teams work differently.
In fact, different team may, and usually do, have different Kanban Boards altogether, with different flow states and different criteria to control that flow, for which they will need different exit agreements. You should take a note that the Flow States in the Kanban Board are can be customized and redefined in any project.
- Portfolio Kanban Boards are built to provide a higher-up business outlook where decisions usually take into consideration more than a single team and more than a single project. You may note that you can not customize or redefine the states of the Portfolio Kanban Board. These states are static across all projects to streamline them for the decision makers. By this same consideration, so go the exit agreements, that are part of these states. Changing the exit criteria to a state is not considered a change 'for the project' or even within the 'confines of a project'. It is considered a change to the state itself which is across projects and hence the exit agreement change will be reflected in similar portfolio item kanban boards for all projects.
Feedback
Yes
No
Powered by
