Same team, multiple releases - How does your company do it with RTC...
- This would give you the 'current iteration' for each release but you have to have each person in multiple team areas - even though all the members are the same for each.
- You still have a clear sense of what features/bugs went into a release, how much work it was and the ability to forecast when the release will be 'done'.
- This would give you a single team, but lose the 'current sprint' forcing a scrum master to constantly update a dashboard to point to all the *current* plans or you leave your team members to navigate to their plans on their own.
- You still have a clear sense of what features/bugs went into a release, how much work it was and the ability to forecast when the release will be 'done'.
- You could just use the main development release and just mark the other work items with a tag for the release that things were checked in on.
- Obviously this is easiest for Scrum Masters and Team members - but really hard for Product Owners.
- You lose the ability to judge how much work went into a particular release, since all of the work is counted in a single iteration. You have no clear way of forecasting when the release will be ready.
4 answers
Comments
Hi Clement,
Hi Lora, this is the screen shot of the parameters for our burndown. You can see one of them is "Releases". Basically if users want to understand the release work, they need to select one or more releases.
Did you make your own BurnDown widget?
Yes, it is one of our custom reports.
How do you enforce that people fill in the 'Targeted Release' Field? Does it automatically pick it up based on the plan/iteration that the Work Item is set?
It's a optional field and currently we don't enforce any dynamic association. The reason is that we have teams that only care about iterations but not releases. In the future, we'd like to set up a dynamic associate between "Filed Against" and "Target Release" so teams will see releases only relevant to them.
we are experimenting with a new workitem type to represent the releasable artifact, metadata and workflows/states instead of the process config 'Releases' table.
If you have a single planning area producing changes to multiple releases, then you can use the "tagging approach" to indicate which release/stream a particular work item will be delivered.
If you have multiple planning areas (e.g. want distinct plans, burn-down charts, etc), then you'll want multiple team areas. If you want to "roll up" the work being done in multiple planning areas, make them child team areas of the "roll up" team area. But that only works if the teams are on the same timeline. If you want the team to work concurrently on multiple timelines, then you'll probably want to add your support to one of the enhancements requested in that area, such as: As a user I want to define a product plan that spans multiple timelines (94056)
Now if you have one team that is working on multiple planning areas, you will have the overhead of maintaining that list of people (and their roles) in each team area. That is unfortunate, and you might want to add your support to work item Allow the membership of a team area to be inherited separately from the timeline and process inheritance (90831)
Comments
I can conceptualize this, but in actuality these people are on a single team. It is hard to convince them that I need to make 3 or 4 different 'team areas' for them to work on a bugs/features and check them into another release or two. It is hard for them to understand why they can't see their velocity for their team, a burn down chart for their team that includes all of the work that needs to be done by their team in a given iteration. The power of plans is completely lost if you need to maintain 3 or 4 in a given sprint.
The RTC model is ONE TEAM, ONE PLAN.
a second RELEASE is a SECOND PLAN. RTC requires the TEAM (definition) to be unique per plan.
as per the enhancements listed above to change the behavior to support what you want it to do.