It's all about the answers!

Ask a question

Need help: categories.. the good, bad, (confusing) and ugly.


Chris Gray (2143) | asked Jan 22 '10, 5:43 p.m.
Sorry for the long post, but I'm struggling with the interplay between Category Mapping / Team Area / Planned For and work items.

Is it just me? Or is the Work Item Categories tab on the Project Area particularly ugly?? ... I find the UI and documentation hard to understand.

For my project
- we have multiple timelines in one project area
- we have separate teams working in parallel for delivery of 2 different releases on different schedules.
- Individuals may need to be moved between or shared part time between the two releases
- we want to use one set of category mappings
- we do have different team names, so when similar teams are working on either releases, they are distinctly identified as Team A and Team B

What I've done is used the Havannah example and a diagram out of the documentation "workflow for projects, teams and process" to create a simple scenario illustrate the problems - and pose my questions...

Scenario:
a) 3 timelines, "Main Development" and "Server Development"
b) each timeline has at least 1 iteration - ex. "Server Iteration 1"
c) 3 team areas - "Core Team", "Server Team"
d) 3 Categories - "Core Applications", "Server"
e) in the Project Area, set Category Mappings as follows
- Visibility is unchecked.
- for each timeline (in the pulldown) - all categories are associated ~ "None" except for...
... timeline "<any>" : all categories associated ~ "None"
... timeline "Main Development" : associate only "Core Applications" ~ "Core Team"
... timeline "Server Development" : associate only "Server" ~ "Server Team"

Action 1)
- Create a new work item using the menu function "File -> New Work Item"

Observation:
- (good) in the new work item, "Project Area" is displayed = "Havannah"; this makes sense since "Filed Against" and "Planned for" are unassigned

Confusion:
- when I select "Filed Against" to "Server"
... I expect the work item to be associated with the "Server Team"
... (bad) the form still shows "Project Area" = "Havannah" and nothing indicating a Team Area

- when I set "Filed Against" to "Server" and "Planned For" to "Server Iteration 1"
... (good) the form changes, replacing the "Project Area" field name with "Team Area" with the (expected) value "Server team / Havannah"

- I also can set bad combinations - "Planned For" to timeline/iterations that aren't associated with "Server",such as "Main Iteration 1"
... (bad) with such a combo, the form simply reverts to "Project Area" = "Havannah" again
... (bad) there is no error, or other indication of a bad choice.

** Question: so what's going on? The documentation is very limted in describing these interactions, so I'm missing not seeing how things are supposed to work together - are there other resources that help into this conceptually and in detail so I can understand it?
** Question: specifically - why does the form switch between showing "Project Area" and "Team Area"?
** Question: Why can I assign work items for a category and/or iteration to people not on the team -shouldn't that be an error or at least a warning??

Action 2)
- the symptoms of 1) above is similar to what happens when I add a new member to a "Team Area"
(I can't recreate this on Havannah since the function is not enabled, but see this on my production system)
... add a member to the "Team Area" "Server Team"
... 4 default work items are created automatically
... (good) the person receives email that indicates the correct "Team Area" - "Welcome to the Server Team"... and "teamAreaPath=/Server Team" in the body

Confusion
- (bad) the 4 work items were created and filed against "Unassigned", with "Project Area" "Havannah" vs "Team Area" "Server Team / Havannah" as I'd expect.

** Question: Shouldn't the "join the team" work item created for a new member on a specific team be correctly set to the "Team Area" or "Filed Against", by default? This seems to be a bug.
** Question: Is there a way to ensure the default Filed Against or Team area to be set correctly?

Action 3)
- same as 1) above, but a person (myself, say) is only a member of the "Core Team"
- in the work item, pick "Filed Against" and "Planned for" values which the person is not associated with - i.e. combinations that set the work item to show "Project Area" = "Havannah" or "Team Area= "Server Team / Havannah"

Observation:
- (good) I see a warning (triangle) icon next to "owned by" name - "Owner does not belong to Team Area"

Confusion:
- (bad) I can assign the work item to the person, with various invalid combinations of "Planned For" and "Filed Against" as above
... (bad) there is no error, or other indication of a bad choice.

** Question: Won't having a work item in this state cause a problem for the owner? I.e. If it wasn't me myself (as an admin) owning the item, but it was assigned to someone on the team, will they be blocked from doing work on the work item when they are the owner flagged as "Owner does not belong to Team Area"... ?? I.e. When does this bad combo become an impediment?

Any clarifications, guidance and suggestions for tactics for now, or (ultimately) product improvements that address this area would be greatly appreciated!

Thanks in advance, Chris

2 answers



permanent link
Chris Gray (2143) | answered Feb 23 '10, 10:49 a.m.
Patrick - I've been meaning to get back to you - thanks! This helped me understand the relationship between categories, timelines and team areas.

My example oversimplified the situation - we have a more complex set up with multiple, parallel timelines, with parallel teams of similar name (example, 2 "build" teams, one on timeline 1 and one on timeline 2) plus categories that are close to the team names (ex. "build" as a category).

To simplify things for users and make it more clear how work gets assigned to specific teams on specific timelines.. I just removed all the default mappings on the <any> timeline - all categories map to the <Root> on the <any> timeline and then for each timeline defined a mapping of category to timeline-specific team.

Now the default for new work items is just the Project Area, and the user needs to pick a specific "Planned For" timeline to assign the work item to a timeline-specific team and timeline combination.

permanent link
Patrick Streule (4.9k21) | answered Jan 25 '10, 7:08 a.m.
JAZZ DEVELOPER
Hi Chris,

Let me start with describing the relation between categories, timelines
and team areas:

A category can have a separate association with a team area for each
timeline.

A category can have a default team area. This is the team area
associated with the category for the timeline selection .

If a category has no team area associations at all, it will be
associated with the project area.

The team area is then determined from the category and the iteration
(Filed Against and Planned For):

1) If the category has an association with a team for the specific
timeline of the 'Planned For iteration' --> That Team

2) If the category has an association with a team for the timeline
--> That default team

3) If the category has no associations --> Project Area

The Team Area is a calculated attribute and not stored in the
repository. More than one combination of category and iteration will
evaluate to the same team area (which is also the reason why these
fields are not populated in the Invite to Team work items).

From the description of your configuration, I would probably choose
this setup:

Associate the 'Unassigned' category (the root in the category editor)
with no team areas. It will then map to the project area.

Associate 'Core Application' with 'Core Team' for the timeline
Associate 'Server' with 'Server Team' for the timeline

The team area will then switch to the respective team depending on the
category, but you will still see all Iterations in 'Planned For':

The current model is 'category + iteration determine the team area'.
This allows to set up different teams e.g. for 'development' and
'maintenance', the typical timelines.

Other requests typically ask for choosing the team explicitly and let it
determine the available iterations and categories. See e.g.:

https://jazz.net/jazz/resource/itemName/com.ibm.team.workitem.WorkItem/95930

For the second problem with the 'Owner'. If an owner is not part of the
team area determined using the steps above, it will be flagged with a
warning (if not, then it is a bug). However, we don't enforce this.
Having an owner outside of the team area has no impact on permissions,
as those are determined by the team area and iteration of the work item.

--
Regards,
Patrick
Jazz Work Item Team

Your answer


Register or to post 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.