Moving a task from a plan to another with different workflow

Sedat kara

(23●11●20) Nov 13 '14, 7:34 a.m.

Hi all,

I am using RTC 4.0.1

We have three teams, A, B and C.

Team A works on a task. This team has its own way to do, so a task has a workflow within this team. When the task is done, it will move to the team B which has also its own way to do and so that the task will have a new workflow to follow.And so on... How can we manage that within RTC? How the task can go to initial step of the team B when it will reach the last state of the team A ?

Alternative solution would be :

Have a global workflow for a task, which can also be possible in our context and each team should see in a Kanban view a part of the workflow (only states in which the team will be involved).

Thanks for sharing your thoughts any idea is welcome :).

0 votes

1 answer

5,723 views

0 votes

One answer

Permanent link

Ralph Schoon

FORUM ADMINISTRATOR / FORUM MODERATOR / JAZZ DEVELOPER (64.6k●3●36●49) edited

Nov 13 '14, 9:27 a.m.

The workflows of work items are managed on project area level. You can not have a work item type with different workflows in a project area. You either have to use 3 different project areas or you have to go for a common workflow.

I personally think a common workflow helps with communication and it makes life of an organization a lot easier and reduces cost (of maintenance). There should be very good reasons for having different workflows.

If you want that, use different work item types, however then users need to know which to use. If you use different project areas and want to copy work items between these the question is what to do with the state.

0 votes

Comments

Ralph Schoon

FORUM ADMINISTRATOR / FORUM MODERATOR / JAZZ DEVELOPER Nov 13 '14, 9:34 a.m.

I guess the decision level is, Use different project areas for the teams with potentially having different workflows. Use one project area and sub teams with a common workflow. For 1 Multiple project areas will prevent seeing the data distributed to them on a plan. If you have hand over of tasks from one to another area you need to come up with how to do that. Moving items between project areas for this case does not seem to be practical, you will likely end up with having multiple work items that need to be created and linked. For 2 you might still end up with having work items for each team, if the need to coordinate on one effort, at least at the execution item/task level.

1 vote

sam detweiler

Nov 13 '14, 1:27 p.m.

or, create unqiue workitem types and do a 'change type' when assigning to Tea B and C task-a, task-b, task-c, each have their own workflow, with the common point being where they change types

1 vote

Sedat kara

Nov 16 '14, 8:32 p.m.

Thanks Ralph and Sam, I think we are approaching the solution with your contributions.I am giving more and concrete information. You find on the image below a quick description of our organization and we would like to have this organization implemented in RTC. We do have in place "Daily Huddles" and would like to use RTC during these quick daily meetings. As you can see we don't have the same way of working within teams, for the sake of clarity I've simplified the steps number for each team. We think about the Sam's hypothesis but how implement it? As the workflow states are common within a project area,we should use different project areas as Ralp suggests? We should also answer this question : how to move a task from a team to another? Thanks a lot for your responsiveness,

sam detweiler

Nov 16 '14, 9:55 p.m.

There are different strategies, depending on the approach. If you had 'design task', 'development task' and 'test task' workitem types, each can have their own workflow. Then you change workitem type when you move it to another team. The workitem need to have a common point in their workflow with the same id. But, given your diagram you have different tasks. Not one. Each starts after the prior ends. So you could create all three when you create the story in this sprint. With a workitem template) And the subsequent tasks are in waiting state or 'new' and on the end of one (done) the next gets moved to open. Or just create the next workitem at the end (done) review of this task. If you keep the same workitem & type you change the category to one assigned to the other team. But the workflow becomes quite large.

2 votes

Sedat kara

Nov 17 '14, 4:19 a.m.

Hi Sam, The first part of your comment is more suitable for our contexte(having 'design task', 'development task' and 'test task' workitem types, each one with their own workflow). The question is how to implement it :) ? When you tell " Then you change workitem type when you move it to another team" you imagine these three different workitems within the same project area or a project area for each team? I don't know how to make them visible in a taskboard or Kanban (like on the image shared previously) view because in a project "State groups" are common to all workflows Thanks,

Ralph Schoon

FORUM ADMINISTRATOR / FORUM MODERATOR / JAZZ DEVELOPER Nov 17 '14, 4:26 a.m.

The latest 5.0.x versions of RTC enhance taskboard capabilities to see more information with respect to states. Especially 5.0.2. See https://jazz.net/downloads/rational-team-concert/milestones/5.0.2M2?p=news#kanbanboard

Sedat kara

Nov 17 '14, 5:11 a.m.

Thanks Ralph, For now I am using RTC 4.0.1 and would like to implement the solution explained in my previous comments, what could be done? Thanks ;)

Ralph Schoon

FORUM ADMINISTRATOR / FORUM MODERATOR / JAZZ DEVELOPER Nov 17 '14, 5:23 a.m.

I think we have pretty much summarized what options you have. I would suggest you go ahead and setup a simple tomcat/derby based eval solution and test out your options and see which one you like best. I personally like Sam's suggestion to use multiple different task types as children. This would limit to one project area, as parent/child does not work across project area boundaries for planning.

Sedat kara

Nov 17 '14, 6:50 a.m.

effefeeefefe Sam's suggestion to use multiple different task types as children implies to have an unique workflow within the project area. In my case, I should combine the three workflows to have one and so that I would have a workflow with at least 13 states. Using a taskboard with 13 states which will be really confusing for people during the daily meetings (having taskboard with 13 states not all these would be used for your team). This is why I would opt for the solution of different project areas (that you also suggested) so that I would have clear taskboard during daily meeting and also clear tasks follow up. Going for this solution pops up a new challenge : change the project area from the work item editor (modify "Project Area" attribute within Workitem editor). How it would be possible? Please correct me, if I am wrong either in my understanding or in my way to do. Thanks for your help,

Ralph Schoon

FORUM ADMINISTRATOR / FORUM MODERATOR / JAZZ DEVELOPER Nov 17 '14, 7:02 a.m.

No, Sam'ts suggestion in fact to have different tasks suggests to have different workflows and thus each workflow would be smaller. If you have multiple project areas and want to move items between them - which I think is not a good idea on a regular basis - you need to use the "Move or copy Work Item to different project area" in the top right corner near the save button.

sam detweiler

Nov 17 '14, 8:15 a.m.

The workitem editor is in only ONE project at a time, so you cannot do this directly. in addition, because the workitems would be in different projects, you cannot display them on a single kanban or task board. using the current RTC products, you would organize the taskboard/kanban display by state GROUPS not STATES.. so you would not need to combine the workflow. But you would not be able to see the exact workflow step by column. as Ralph mentioned, using 5.0.1 allows you to add the individual states to the state group display header in the task/kanban board. Til 5.0.1 it is very hard to get the kind of display you want. and currently up to 5.0.1 there is only ONE taskboard/kanban board layout per project area. so you cannot do it differently by team or logical work product

showing 5 of 11 show 6 more comments

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.

Follow this question

By Email:

Once you sign in you will be able to subscribe for any updates here.

By RSS:

Answers

Answers and Comments

Question details

rational-team-concert

× 43,075

usage

× 12,144

Question asked: Nov 13 '14, 7:34 a.m.

Question was seen: 5,723 times

Last updated: Nov 17 '14, 8:15 a.m.

Moving a task from a plan to another with different workflow

1 answer

5,723 views

0 votes

One answer

Comments

Your answer

Follow this question

Question details

Related questions