It's all about the answers!

Ask a question
QuestionsTagsUsersBadges
Guidelines | FAQ
Follow this question
Question details

×42,877
×1,221

question asked: May 20 '13, 9:24 a.m.
question was seen: 5,820 times
last updated: May 21 '13, 7:52 a.m.

Related questions

Same team, multiple releases - How does your company do it with RTC...

0
Lora Estey (73●3●19●20) | asked May 20 '13, 9:24 a.m.
Since RTC doesn't do a great job at handling the idea that a single team would work on multiple releases at any given time, I would like to know how other companies are handling this. I know that we could do it any of the ways that I'll list below, but I want to know what the specific pain points are here.

We always have a service pack, a current developmental release and a future release - I can't imagine that this isn't common.

Do you use different timelines with the duplicate 'teams' tied to each timeline?
  • 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'.
Do you use the same timeline and then have identical sprints (same sprint cycle under each release..)?
  • 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'.
Do you use another field to mark the other releases that people are working on?
  • 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.
Do you use dashboards to alleviate the pain?

I know that all of these are possible, but I want to know specifically what other people are doing and how they were able to 'sell' the solution to their RTC users.


4 answers

Most liked answers ↑|Newest answers|Oldest answers

0
permanent link
Clement Liu (1.5k●5●43●49) | answered May 20 '13, 10:01 a.m.
We created a custom W.I. field - Target Release in addition to the Planned For field. In this way, teams can work on multiple releases at the same time. 

Hope it helps. Thanks.
Comments
Lora Estey commented May 20 '13, 11:32 a.m.

 Hi Clement, 

Do you use Release burndown charts for the other releases? How do you factor this work into your other releases?

Clement Liu commented May 20 '13, 12:46 p.m.

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. 



Lora Estey commented May 20 '13, 1:11 p.m.

Did you make your own BurnDown widget? 

Clement Liu commented May 20 '13, 1:21 p.m.

Yes, it is one of our custom reports. 

Lora Estey commented May 20 '13, 1:30 p.m.

Thanks so much Clement!
I have another question. 

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? 


Thanks!
Lora

Clement Liu commented May 21 '13, 7:52 a.m.

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. 


Hope it helps. Thanks!

showing 5 of 6 show 1 more comments
0
permanent link
sam detweiler (12.5k●6●195●201) | answered May 20 '13, 11:58 a.m.
We are considering a similar Target release field, AND a Delivered Release field (list) and then this affects Found In for defects.. (list).. our dev teams used these same fields on other system before coming to RTC.

we are experimenting with a new workitem type to represent the releasable artifact, metadata and workflows/states instead of the process config 'Releases' table.
0
permanent link
Geoffrey Clemm (30.1k●3●30●35) | answered May 20 '13, 4:34 p.m.
FORUM ADMINISTRATOR / FORUM MODERATOR / JAZZ DEVELOPER
The first thing I'd recommend is conceptual ... think of your "team areas" as "planning areas" (i.e., focus the definitions of your team areas on the planning process, not on the set of people who will be doing the work).  
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
Lora Estey commented May 20 '13, 4:44 p.m.

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 over head of creating and maintaining the team areas isn't the pain point here. It is the fact that they cannot really use the plans as they are intended.

0
permanent link
sam detweiler (12.5k●6●195●201) | answered May 20 '13, 4:52 p.m.
edited May 20 '13, 5:23 p.m.
> It is the fact that they cannot really use the plans as they are intended.

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.

Your answer

Register or to post your answer.


Dashboards and work items are no longer publicly available, so some links may be invalid. We now provide similar information through other means. Learn more here.