Hi Millard,

can you make sure in the project overview tab you have indeed the scrum process template deployed for your project?
If that is the case you should find the plan types in the Process Configuration tab in Project Configuration>Configuration Data>Planning>Plan types.

I think you can only configure time lines and iterations for teams in the same project as the plan. I don't see how you could do something wrong here, provided you tried to create the plan in the right project.

Ralph

The Project Area is set to use the Scrum template. Work item categories are established and mapped to appropriate Team Areas. The Team Areas are set to inherit their process from their parent (Project Area).

When I create a new plan, I should see "Sprint Backlog", "Product Backlog", etc. However, I'm seeing the OpenUP names instead. I saw a comment somewhere that said the plan types were also affected by the timeline associated with the team area -- is that right? I could not figure out how the timeline setting would affect that (no properties I could find that would adjust this).

1. How do I get the right names to show up?
2. Are the plan behaviors identical (just the wrong name showing up)?

Thanks...Millard

Hi Millard,

the scrum template has been completely changed in 2.0. The plan types did not exist in 1.0.

Did the administrators just updated from 1.0 to 2.0 and continued to use the old Scrum template? Please ask them to re deploy the new Scrum template and create a new project using that. Please check the plan types are correct in the new project.

Thanks,

Ralph

PS: Thanks for the great demonstrations on Scrum at Jazz.net and Techworks.

PS: Thanks for the great demonstrations on Scrum at Jazz.net and Techworks.

My pleasure, thanks for noticing.

It looks like the templates were _not_ updated as part of the 1.0.1 -> 2.0 upgrade. We're going to do a backup tomorrow and then push the new templates.

How much "danger" is there to existing Project Areas on the system? Should I rebuild/redo anything to make sure the changes are picked up? Rebuild the timelines or already made plans?

Thanks...Millard

Hi

Did you use the "deploy the templates" option at any stage after upgrading. This loads the new 2.0 templates into the repository. Otherwise, the existing 1.0 templates will be the only ones available in your repo.

Deploying the new templates makes no changes to existing project areas. You need to manually alter the existing projects with any new capabilities from the 2.0 templates.

If you have modified the original templates and not changed the names of the template - you might overwrite the existing templates with the new 2.0 ones.

Finally, we noticed that our 1.0 templates did not appear on the list after the upgrade. This is only because there is now a language filter on the templates - setting it to all languages makes the old templates re-appear in the list. You need to set the language on your old process templates for them to appear for a specific language.

regards

anthony

Deploying the new templates makes no changes to existing project areas. You need to manually alter the existing projects with any new capabilities from the 2.0 templates.

Any instructions anywhere about how to manually alter existing projects? Is that just a copy/paste of a process xml file contents or is it a multi-step, stuff can go wrong at every turn sort of thing?

How easy to make a new Project Area, export the current data and import it into the new one? Would that pick up everything?

Since I didn't do the install/upgrade, I'm not sure how obvious it was that the templates needed to be deployed after the upgrade. If there aren't big giant red sections saying that you need to do this, there probably should be. Not much of an upgrade if that stuff isn't picked up also.

What I imagine most people don't want is an upgrade altering their process on a project "in-flight". But agree that that we should warn people that they might want to update their project process to take advantage of capabilities in the new 2.0 templates.

The upgrade process does make sure that existing projects behave as before after the upgrade, and it also alters the existing *templates* in that it makes sure they work on the new repository - but again, will not add new capabilities available in 2.0.

There is guidance on how to change an existing project instance here:

https://jazz.net/wiki/bin/view/Main/UpdateTemplatesAndProjectsFor20

The process is a manual one - you need to look at the new process templates, and add the bits you require into your existing project (or team) process.

There is also a work item that asks that this documentation be made more visible.

I recall seeing information about what happens to project templates and the project process instances somewhere in the upgrade notes, but don't have that to hand.

regards

anthony

Moving a project area to a new version of the template is not a trivial operation. The basic approach is as you suggested: deploy the 2.0 templates, make a project area with the latest version of the template, copy the changes.

I have been working on more specific guidance with this topic: https://jazz.net/wiki/bin/view/Main/ProcessUpdateForExistingProjectAreas. BUT, I have recently been informed the instructions may not work due to changes in workflows between RTC 1.0 and RTC 2.0.

You can follow the discussion in this work item:
https://jazz.net/jazz/resource/itemName/com.ibm.team.workitem.WorkItem/94372

Martha
Jazz Developer

Deploying the new templates makes no changes to existing project areas. You need to manually alter the existing projects with any new capabilities from the 2.0 templates.

Any instructions anywhere about how to manually alter existing projects? Is that just a copy/paste of a process xml file contents or is it a multi-step, stuff can go wrong at every turn sort of thing?

How easy to make a new Project Area, export the current data and import it into the new one? Would that pick up everything?

Since I didn't do the install/upgrade, I'm not sure how obvious it was that the templates needed to be deployed after the upgrade. If there aren't big giant red sections saying that you need to do this, there probably should be. Not much of an upgrade if that stuff isn't picked up also.

What I imagine most people don't want is an upgrade altering their process on a project "in-flight". But agree that that we should warn people that they might want to update their project process to take advantage of capabilities in the new 2.0 templates.

The upgrade process does make sure that existing projects behave as before after the upgrade, and it also alters the existing *templates* in that it makes sure they work on the new repository - but again, will not add new capabilities available in 2.0.

There is guidance on how to change an existing project instance here:

https://jazz.net/wiki/bin/view/Main/UpdateTemplatesAndProjectsFor20

The process is a manual one - you need to look at the new process templates, and add the bits you require into your existing project (or team) process.

There is also a work item that asks that this documentation be made more visible.

I recall seeing information about what happens to project templates and the project process instances somewhere in the upgrade notes, but don't have that to hand.

regards

anthony

millarde wrote:

@kesterto - agreed that I wouldn't want the upgrade process to just
trounce all over my nicely customized process template, but we need a
real story for how to incorporate these improvements to existing
projects. It's a real barrier to upgrade, largely because people
_should_ be constantly tweaking their process to reflect changes the
team has agreed to -- and we don't want them afraid to upgrade to a
newer version of the product.

@mandrew - thanks for the extra links and insights. Do you think it
is the case that the "unchanged configuration" is in danger
of not working based on the workflow concerns you note? We are
fortunate enough to be very early in the process for our next
release, so I can probably get away with a swap on the source (there
have been no revisions so far) unless that case is in danger of not
working also.

Thanks to both of you for sticking with this thread and helping me get
this worked out. This will likely affect many teams using RTC (and
working to move to 2.0) in my organization.

Hi Millard,

We've spent a lot of time since 2.0 GA trying to merge Scrum 2.0 changes
into our process configuration which is based on Scrum 1.0. Let me know
if you want to discuss.

You might take a look at work item 94249. I'm fairly sure that applying
the Scrum 2.0 process template to a Scrum 1.0 database, even if there
have been no modifications made, which has been upgraded from RTC 1.0 to
RTC 2.0, will result in a database with problems.

Mark Ingebretson