Long living Release Backlog
Main Development (timeline)
Product Backlog
Release Backlog
Sprint01
Sprint02
.
.
Sprint n
In 3.0.1.4, when sprints are completed, we archive the sprint and the iteration (and work items) were no longer included in our Release Backlog plan. After upgrading to 4.0.3, archiving does not remove them from Release Backlog plan which is impacting our Release Backlog plan performance as well as a crash (work item -> https://jazz.net/jazz/web/projects/Rational%20Team%20Concert#action=com.ibm.team.workitem.viewWorkItem&id=283781). As a work around, I created a new "Complete" iteration as a peer to the Release Backlog and move complete sprints under it.
Is the behavior change between 3.0.1.4 and 4.0.3 design or a bug (behavior -> including archived Sprints in the Release Backlog)?
If by design, what is the recommended way to manage a Release Backlog that lives a long time (potentially for ever)?
One answer
Comments
We are not currently filtering execution items as we find exeution items useful in the release backlog for planning purposes (story breakdown and sizing).
I asked about resolved items -- that seems to be your concern. Resolved items are showing up in your plan (and you don't want them).
Even excluding resolved items (and execution items) we're having issues with the Eclipse client to load big backlogs. There is something wrong in how RTC manages the query parameters (i.e: The Eclipse client recommend having less than 2048 workitems, and the query results shows that 1100 meet the criteria, and still crashes).
Have you tried the web client for reviewing these plans? Significant effort went into improving performance of large plans in the web client in 4.0.1 and later. Most planning improvements happen in the web client and it is the preferred client for planning activities. Can you try using the web client and let me know if it also crashes there? In your Eclipse client, are you using the basic RTC version? Have you looked at memory settings and other ways to improve the Eclipse client performance? i'm trying to determine if you have uncovered a defect in RTC or there are issues with the client configuration.
Thanks Millard for your answer. We have had the same issue in the web client (from a remote site). Although the default view configuration excluded execution items, I unchecked the option of "Always load execution items" in the plan configuration, and now it works (for me). Next week I will ask the people having these issues in the web client to test again to see if the issue finally was resolved... So my question is, even when both configuration seem to do the same (un-checking the option vs adding a Exclusion criteria in the view editor), the query that is build is totally different?
Thanks.
Hello Juan, regarding the difference between the "Include All Items" flag in the plan details vs excluding execution items in the plan view config, there are some important differences. The plan view exclusion filter is a client-side view filter that will exclude any execution items that have been retrieved from the server. The "Include All Items" flag actually determines whether the plan will show execution items from sub-teams of the "Plan Owner" and execution items from past iterations - if this option is not checked then such items are not retrieved to be displayed in the plan. Note that this option is labeled as "Always load all execution items" in the Eclipse client. There was a point where it behaved differently between the Eclipse client and web UI, but this was addressed in 4.0.1 with - "Always load execution items" flag not working correctly in eclipse client (243043)
Comments
Millard Ellingsworth
FORUM ADMINISTRATOR / JAZZ DEVELOPER Oct 08 '13, 10:36 p.m.I'm not understanding why you would archive a sprint. What were you hoping to accomplish by doing that? I think a Sprint is a relatively light-weight item that just defines a period of time to which you can plan a work item (and potentially define specific operational behaviors). While I can understand a Product Backlog that lives "forever", I'm not seeing how your Release Backlog lives beyond the upcoming release.
Erik anderson
Oct 09 '13, 7:47 a.m.Thanks Millard,
We release to the cloud frequently and are working toward releasing even more frequently (mini releases). We use sprints for our mini releases and use the Release Backlog to flesh out work that is then moved to the sprints for execution. When the sprint is complete we are no longer interested in the work items.
In 3.0.1.4, archiving would remove the work items completed in the sprint from being included in the Release Backlog plan. In 4.0.3 it does not.
Is there a better way to use iterations?
Millard Ellingsworth
FORUM ADMINISTRATOR / JAZZ DEVELOPER Oct 09 '13, 11:32 a.m.Interesting. Do you have really short sprints (like a couple days)? Do you close each sprint after each push to production? Do you actually "do scrum", i.e., have a planning meeting, standups and a retrospective for each mini-release (or on some fixed interval)? As you reach a continuously releasing state (which it sounds like you are heading for), it feels like a true Kanban style approach would be a better fit than Scrum. I've been pushing for a real Kanban process template and support for a while now, perhaps I can use your use case to push some more. :-)
Erik anderson
Oct 09 '13, 2:24 p.m.My group supports a large development community and the approach mentioned above is a common theme. As far as I know, the dev groups are using some form of planning meetings, standups, and retrospectives but I can't comment much more than that.
Our org is very interested in what we need to change re. planning and continuous delivery. I'll contact you directly to share more notes.