It's all about the answers!

Ask a question

Promote a work item type to appear as a top level (plan) item in Plans


Nil Bond (132) | asked May 11 '15, 5:31 a.m.
AFAIK, if you make plans, stories and epics show up as top level or plan items and rest are execution items. We are planning to start RTC and are still in the planning process. Say if a product manager wants to track progress and see only top level items but also some critical bugs that might be effecting customers, how can he achieve that?

Since, developers file bugs under categories which are basically building blocks of the product/software (e.g. GUI, Framework, Tests) and as "Defects", how can some these items be included in a top level plan? We are not allowed to create custom work item types as per the company master process configuration.

Thanks in advance!

Accepted answer


permanent link
Ralph Schoon (55.5k23642) | answered May 11 '15, 6:11 a.m.
FORUM ADMINISTRATOR / FORUM MODERATOR / JAZZ DEVELOPER
They can not and the mechanism is to have plan items to track multiple changes. Here is the configuration:
Execution types such as defects should not be used as Plan items, as the effort tracking and roll up depends on them being configured as execution items.
You can try to create a plan view that groups by category.
Nil Bond selected this answer as the correct answer

Comments
Nil Bond commented May 11 '15, 9:21 a.m.

Thanks Ralph. The way you explained things sounds logical but consider this use case.

If there is an bug found by a GUI developer/customer, the GUI developer will file it under GUI category and also see it under the GUI sprint backlog (plan belonging to the GUI team). However, lets say the product manager who is situated in some upper level node of the team hierarchy wants to track it (say the product manager decides if this bug should be dealt now or postponed to another future iteration), how would he end up seeing this bug in "his" plan which may exclude execution items and items from subteams.

Hope I dont sound like a confused mess!


Nil Bond commented May 11 '15, 9:22 a.m.

Thanks Ralph. The way you explained things sounds logical but consider this use case.

If there is an bug found by a GUI developer/customer, the GUI developer will file it under GUI category and also see it under the GUI sprint backlog (plan belonging to the GUI team). However, lets say the product manager who is situated in some upper level node of the team hierarchy wants to track it (say the product manager decides if this bug should be dealt now or postponed to another future iteration), how would he end up seeing this bug in "his" plan which may exclude execution items and items from subteams.

Hope I dont sound like a confused mess!


Ralph Schoon commented May 11 '15, 9:42 a.m.
FORUM ADMINISTRATOR / FORUM MODERATOR / JAZZ DEVELOPER

Nil,

there are plans for overview and there are plans for other things. You can use different plan views if you want.

It is also possible to use tagging and other means like coloring to make certain things more obvious. It is not necessary to do everything in a plan either. Sometimes dashboards and the like are better suited to help.

With respect to your defect scenario, it is possible to have a dashboard and query that shows the latest incoming defects. You usually would also have some person to manage newly incoming defects to prioritize them and make sure they make sense. Usually this person or some board would look at incoming work and prioritize it. If the defect is so important, you might want to change the type or add a parent item that tracks it.

Just some thoughts.


Ralph Schoon commented May 11 '15, 9:49 a.m.
FORUM ADMINISTRATOR / FORUM MODERATOR / JAZZ DEVELOPER

Dependent on which version you are on, you might even want to look into the Quick Planner, as this might be another tool that the manager might want to use with filters and the like.

Your answer


Register or to post your answer.