Product backlogs are represented as an iteration in RTC because an
iteration lets you do all the things that you normally want to do with a
backlog. Logically, a backlog is the "catchall" iteration, for all the
things that aren't assigned to another iteration.

Note: In version one, RTC had a separate concept of a backlog, but we
kept getting requests to be able to do additional things to the backlog,
and those things were already supported on iterations. So in later
releases, we just made the backlog be an iteration, and marked all those
enhancement requests as "Done".

Cheers,
Geoff

On 10/27/2011 9:38 AM, rlissimore wrote:

I'm evaluating RTC at the moment (i.e. a n00b), and some of it is a
little confusing.

So I need to create a product backlog, which in the Scrum universe is
its own artefact, separate from any sprint or iteration.

In RTC, I create a new plan and configure it to be a Product Backlog.
It automatically assigns it to a Sprint that I'd previously
configured (Sprint 0).

Why do Product backlogs have to be in an iteration/sprint in RTC? Is
there any way to have the Product Backlog and Release Backlog
separate from any sprint?

Cheers,

R

If the question is "Is there anything else I personally will find
non-intuitive", then the answer almost certainly will be "yes".
Probably the best way to find things that others have found
non-intuitive would be to browse this forum.

Cheers,
Geoff

On 10/28/2011 9:23 AM, rlissimore wrote:

I'd argue the difference between a list of work to do (backlog) and a
period of time (iteration), but it won't change how it works.

Are there any other quirks like this in RTC? Anything that isn't
straightforward?



gmclemmwrote:
Product backlogs are represented as an iteration in RTC because an
iteration lets you do all the things that you normally want to do
with a
backlog. Logically, a backlog is the "catchall"
iteration, for all the
things that aren't assigned to another iteration.

Note: In version one, RTC had a separate concept of a backlog, but
we
kept getting requests to be able to do additional things to the
backlog,
and those things were already supported on iterations. So in later

releases, we just made the backlog be an iteration, and marked all
those
enhancement requests as "Done".

Cheers,
Geoff

On 10/27/2011 9:38 AM, rlissimore wrote:
I'm evaluating RTC at the moment (i.e. a n00b), and some of it is a
little confusing.

So I need to create a product backlog, which in the Scrum universe
is
its own artefact, separate from any sprint or iteration.

In RTC, I create a new plan and configure it to be a Product
Backlog.
It automatically assigns it to a Sprint that I'd previously
configured (Sprint 0).

Why do Product backlogs have to be in an iteration/sprint in RTC?
Is
there any way to have the Product Backlog and Release Backlog
separate from any sprint?

Cheers,

R

I would not think to much why a backlog is represented in RTC as an Iteration. It must be something and the Object Iteration has the functionality you need to build a Backlog.

A Backlog must not be in a Sprint. I have it parallel to a Sprint.

My favorite setup is

timeline

uncommitted
Release

Backlog
Sprint 1
Sprint 2
Sprint 3

This allows me to create following plans:

- Product Backlog > uncommitted (Type Product Backlog)
- Release Plan > Release (Type Release Backlog)
- Release Backlog > Backlog (Plan Type Product Backlog)
- Sprint Plan > Sprint x (Plan Type Sprint Backlog)

(Note: If you use Plan type Release Backlog for the Release Backlog, at least the Advanced Burndown Chart report will not work, because there it is not allowed to select two Iterations where a Release Backlog Plan exists.)

What I absolutly dont like, and it confuse the users, is the word Backlog in the plan types. But its just a word.

regards
Guido