I experienced some inconsistent behavior in using the Team Release and
the Release plan in 2.0.

Basically I am usually working with a project migrated from 1.0.1.1
based upon the Eclipse way Process. Project and Team release plans in
this project never show any execution items, regardless how the check
box for this filter is set.

Contrary, in a new project based upon the SCRUM template I created I
am able to see execution items in the plan consistent to the filter
setting.

Which behavior should I expect in general? Is this something that can
be changed in the process template (maybe hidden?).

BTW: I found this work item
https://jazz.net/jazz/web/projects/Rational%20Team%20Concert#action=com.ibm.team.workitem.viewWorkItem&id=84088
that talks about import issues but i am not aware of issues with the
migration.

Only execution items specifically planned for the iteration and filed against the team area, for which the plan is configured, are loaded from the server.
The filter checkbox only operates on the work items loaded. Release plans only aggregate top level work items from the respective child team areas and/or child iterations.

I assume that you checked the category/timeline/team configurations to be correct?

Defect 84088 describes a problem with the process configuration which causes the plan to fail, but this is not the issue you are seeing, as the planned items tab would be completely broken otherwise.

--
MikeS
Jazz Agile Planning team

rschoon wrote:

Hi Michael,

thanks for the answer.

I believe my category settings are correct.
I took some time to look into it and made some new observations.

In the migrated Project Release plans show new execution items if the
execution Item filter is off but they only show these work items
planned for the release and assigned to the team the plan is
configured for. To be more specific, as soon as I plan them for a
iteration within the release or assign them to a sub team, they
simply go away. The same with team release plans.

This behavior is contrary to the behavior of top level work items
which show up in case the team is a sub team or the iteration is
nested in the release. I would have expected to have a consistent
behavior.

I will check my new project today and provide additional information.

This is how the plan is designed to work. We do not load execution items of child iterations and/or team areas, as this would load way too many work items (which are probably not of interest).
We do, however, load the top level work items, as in a normal setup this is a manageable number of work items.
Additionally, we assume that the top level work items are the ones that really indicate the progress of the child iterations.

--
MikeS
Jazz Agile Planning team

rschoon wrote:

This is how the plan is designed to work. We do not load execution items of child iterations and/or team areas

I've opened Enhancement 96219:

"The help states: "A Team Release plan that is associated with an iteration displays all the work items of that iteration and all the top-level work items of its child iterations." I would like some type of plan which contains all of the work items from the child iterations, not just the top-level work items. Ideally this would be the behavior of the Team Release Plan, with perhaps a new filter to allow exclusion of child iteration execution items to mimic the current behavior. The benefit of such a plan is that it provides you with a convenient record of all that has been done in a release. The Iterations grouping is especially useful for this. But with the current behavior you have to open each child iteration plan to see a record of what was delivered in the specific child iteration."

The behavior is inconsistent indeed.

Consider the following scenario:
- I have my product backlog opened
- I have stories in the product backlog that have tasks under them; these stories had tasks in a previous iteration but were assigned back to the backlog because they could not be completed in this iteration
- I only see the stories in the backlog no matter whether I filter for execution items or not (which is definitely not what I want)
- I change to the iterations view mode
- I assign such a story to an iteration
- I open the corresponding iteration plan; I realize that the tasks did not follow the story and therefore are not assigned to the iteration (which is not a desirable behavior)
- I bring my product backlog back to foreground
- I remove the Exclude filter for Execution items......
and - voil - I see the tasks!!!

In this volatile situation, I can move the tasks to the iteration, too.

But be careful not to save the backlog in between; if you do that, the tasks are invisible again!

There are also some other situations in your teams planning where you just need to see tasks in the product backlog.
This means that the filter checkbox "Execution items" must allow you to see your tasks in the backlog.

(1) The current behavior is inconsistent.
(2) Even after reading the replies above, I do not think that not showing tasks in the backlog is the right approach at all. I really would like to see this changed.

Another example why I must see my tasks in the backlog:

- Imagine that I could not complete a story in an iteration
- Therefore I open the iteration backlog as well as the product backlog and arrange them such that I can drag the story from the iteration back to the backlog
- Then I get a prompt that asks me if I want to move the children as well - which is a very good behavior
- After the move, I see the tasks in the product backlog - no matter whether I select to exclude execution items or not
- When I now save the iteration, the story and the tasks are gone - which is well expected at that time
- The tasks as still visible in the product backlog although the save button is not even enabled any more
- If I now refresh or close/reopen the backlog, the tasks are gone again (which is again not a desirable behavior at that time)

Question:
How do I then move the story including its children from the backlog to my next iteration?

The only circumvention I see is to specify "Tasks" as "Top-level work item type" which is definitely not what I want because tasks should better keep the semantics of execution items.