operation behavior team vs iteration
![]()
- I have a project area A -> child team B -> child team C.
- Project area 'shutdown' iteration type has a delivery rule for Everyone: 1 review + 1 approval. - Team B owns the stream and has operation behavior (team rule! not iteration) delivery rule for Everyone: 1 review + 2 approvals. - This is shutdown iteration 'Sprint 31', but I want to allow team C to deliver with just 1 review - at which level to I override operation behavior for C: 1. C team area 2. C 'shutdown' iteration 3. 'Sprint 31' for team C ? The confusion here comes from the precedence - what precedes what: team's operation behavior or iteration (or iteration type) operation behavior ? |
One answer
![]()
Ralph Schoon (63.3k●3●36●46)
| answered Mar 08 '13, 2:00 p.m.
FORUM ADMINISTRATOR / FORUM MODERATOR / JAZZ DEVELOPER
Please read https://jazz.net/library/article/292 . It is still valid and explains it.
Comments In general you specify behavior across team level. You can add behavior at iterations. It can also be hierarchical in iterations and can be at a level nested into planned for iterations. For example you can split a release iteration into smaller chunks e.g. To make a process more strict towards the end of an iteration. It can also tied to iteration types. Thanks. I did read that article and posted question after reading, it did not help with the team vs iteration rule precedence.
also not clear rule composition/precedence when it comes to concrete iteration (instance) vs iteration type (e.g. 'shutdown') - is is additive or does concrete interation override type imposed rule ? (all for same role, to make things simple)
It grabs the first role of the user in the team are that owns the object to manipulate/ act on. Then it starts with the deepest nested iteration, looks at the type, if no type at the iteration and looks for operational behavior. It looks fo the first operational behavior definition it can find for the role. If it finds a definition for an operation that is involved, for the role, that is picked, and only that. If it doesn't it looks at the team area, does the same. And up the team area hierarchy. It does this for all roles until it finds the first operational behavior. It only executes the first it finds.
A check mark with no operations specified means no operation. Operational behavior is not accumulated.
Oh, I see, so it executes the first found, looking team area-wise locally first - 1) current iteration, 2) iteration type, 2) team area, and going up the team hierarchy making the same rounds at each level, until it finds a definition for the given role. Did I get it right ?
|
Your answer
Dashboards and work items are no longer publicly available, so some links may be invalid. We now provide similar information through other means. Learn more here.