For what is the "Backlog Iteration" definition

The "backlog" iteration is primarily a way to easily identify what iteration contains the "backlog", i.e. "not-yet-in-plan" work items. Since you are free to customize the names of all the iterations, there would not otherwise be a reliable way for someone to find the unplanned items.

WRT why it is recommended as a top level iteration, the purpose of the backlog iteration is by definition to capture "not yet planned" work items. So it doesn't make sense to have not yet planned work items to be in any plan other than the "Backlog Plan".

Cheers,
Geoff

In the process you can define one Iteration per Timeline to become a "Backlog Iteration". In the Scrum Template it is set to the Iteration called "/Backlog".

Unfortunatly the text in the UI is not very self explaining. Plus, if I set this to an iteration which is not a Root Iteration, I get the warning, "It is highly recommended to use a Top level Iteration".

Can anybody exactly explain for what this special attribute is? What is happening with Work Items and their points/hours etc. if they are in this Iteration? Only special effect I saw until now is, the special Icon.

And why should it be a top level Iteration? It is not realy usefull to have the Backlog on top parallel to the Release Iteration, because you cannot build a plan with both in it. You need a Iteration above the Backlog and the Release to get a plan where both is in.

regards
Guido

My Summary based on your comment:
- there is NO technical restriction, if the BACKLOG ITERATION is NOT a top level Iteration.
- this flag is just to get the nice Iteration Icon, so the backlog is better identifiable, if the naming convention of plans is not good enough.

One word about your comment:

"So it doesn't make sense to have not yet planned work items to be in any plan other than the "Backlog Plan". "

I do not completely agree with this.
We have in our projects at least two backlogs where we have "not yet planned" work.
- "Product Backlog": this maybe on top level
- "Release Backlog": this is a backlog Iteration parallel to the Sprint Iterations INSIDE each Release Iteration.

Additional comment:
- the "Product Backlog" we don't have on Top level, because we want to have a FULL plan where we get ALL WorkItems, regardless if they are in the "Product Backlog" or in a "Release" or a child Iteration of the "Release". Today you cannot bind a Plan to the Timeline only to an Iteration. This means for a Full Plan you must have a Dummy Iteration on Top, where you don't plan a Release for, so you cannot plan workitems for.

- The "Release Backlog" we are doing, because we don't want to have this Workitems just in the "Release". If you have them in the "Release", you cannot Collapse them in the Plan-Iteration View, you don't have any bars in the Iteration view and you cannot do a Release backlog where you only get this unplanned items. By setting the Plan Details. You can only do Browser based filtering and this slows down the load.

So our Iteration Structure looks like:

Timeline (project timeline

   Product (no release planned for)

      Product Backlog

      Release 1 (no release planned for)

         Release 1 Backlog

         Sprint01

         Sprint02

         Sprint03

Regards
Guido

WRT having every work item (including everything in the backlog) in a
single plan, I agree that can be useful, but doesn't scale well if you
have a lot of work items in backlog.

WRT having explicit release backlogs, I've always just used the release
iteration itself as the backlog bucket for the iteration, but I agree
that having explicit release backlog iterations has the benefits that
you identify.

Cheers,
Geoff

On 2/28/2012 4:38 AM, schneidg wrote:

My Summary based on your comment:
- there is NO technical restriction, if the BACKLOG ITERATION is NOT a
top level Iteration.
- this flag is just to get the nice Iteration Icon, so the backlog is
better identifiable, if the naming convention of plans is not good
enough.

One word about your comment:
gmclemmwrote:
"So it doesn't make sense to have not yet planned work items to
be in any plan other than the "Backlog Plan". "

I do not completely agree with this.
We have in our projects at least two backlogs where we have "not
yet planned" work.
- "Product Backlog": this maybe on top level
- "Release Backlog": this is a backlog Iteration parallel to
the Sprint Iterations INSIDE each Release Iteration.

Additional comment:
- the "Product Backlog" we don't have on Top level, because
we want to have a FULL plan where we get ALL WorkItems, regardless if
they are in the "Product Backlog" or in a
"Release" or a child Iteration of the "Release".
Today you cannot bind a Plan to the Timeline only to an Iteration.
This means for a Full Plan you must have a Dummy Iteration on Top,
where you don't plan a Release for, so you cannot plan workitems
for.

- The "Release Backlog" we are doing, because we don't want
to have this Workitems just in the "Release". If you have
them in the "Release", you cannot Collapse them in the
Plan-Iteration View, you don't have any bars in the Iteration view
and you cannot do a Release backlog where you only get this unplanned
items. By setting the Plan Details. You can only do Browser based
filtering and this slows down the load.

So our Iteration Structure looks like:


Timeline (project timeline
Product (no release planned for)
Product Backlog
Release 1 (no release planned for)
Release 1 Backlog
Sprint01
Sprint02
Sprint03


Regards
Guido