Remove comments field on transition

[Stefano Rosario Aruta]

how to remove comments field on transition

this code it does not work:::::

import com.atlassian.jira.issue.Issue;
import com.atlassian.jira.issue.fields.layout.field.FieldLayoutItemImpl.Builder
import com.atlassian.jira.component.ComponentAccessor
def c = ComponentAccessor.getCustomFieldManager().getCustomFieldObjectsByName("comment");
c.setHidden(true);
//issue.getFieldById("Comment").setHidden(true);

[Phill Fox]

Hi Jim,

I would set up two Agile boards based on the following filters. 

project = <key>  AND (team is empty or team = "Team A")

project = <key>  AND (team is empty or team = "Team B")

Using this both teams see the shared backlog of issues not yet allocated to a team and all items allocated to their team. 

A refinement is to add a quickfilter to show team="Team A" so they only see those items allocated to Team A.

Your reports will then work correctly for each board only showing the work undertaken by each team.

[Jim Constant]

Thanks, Phil.

I think this might not give me the project level reporting I need. Backlog 2 is much smaller so we're operating under the assumption that this will be done long before Backlog 1. So our eye is on Backlog 1 and we need the reporting on that backlog to show progress and projections based on the work no matter which team worked on it (think the Version Report, for example). With the filters you described, that wouldn't work I'm afraid.

Do you think a 3rd board that would show all would do it? The team could work from their specific boards but we do our reporting from the higher level board that shows all work.

Jim

[Phill Fox]

Hi Jim,

So if you are willing to accept that Backlog 2 will be covered very quickly, then you could just look at the information for Backlog 1 and treat that as your project backlog.  

Certainly having a 3rd board would allow you to see some progress reports but would lead to potential conflicts between the sprints on each board. At the moment you really need to have issues in a single sprint on a single board rather than on multiple.

Another alternative which is not fully supported is the ability to have parallel sprints which need to be enabled as they are part of the Atlassian Labs section. This would allow you to have two sprints running at the same time - one for each team. But we aware this does some weird things to reports if the velocity of the two teams are different.

Hope this helps a bit more.

Phill

[Jim Constant]

Hi Phil,

Yes, we plan to treat Backlog 1 as our project backlog and I think it's going to work the way I have it set up.

And you're right about the potential conflicts of a 3rd board, however, I think I might be able to protect against that if that board is the only one that pulls from two separate backlogs. The team's sprint are already running in parallel. And because they're both pulling work from a common backlog, we have to sync up on story point sizes no matter what we do. I think that would take care of the reporting concerns. Assuming those conditions, can you think of anything I'm not thinking of?

BTW, I thought about the parallel sprint features but it just sounds half baked so I don't think I'll go there if I can at all avoid it.

Thanks,

Jim

[Phill Fox]

The only other thing I can think of to consider is the impact of when backlog 2 is completed and what does Team B then do? Do they get redeployed on other projects or swap to dealing with issues from Backlog 1? 
Depending on your answer t this will impact what happens to your sprint velocity and therefore your predictions for completion. 

Phill

[Jim Constant]

Team B will eventually be disbanded with some folks going to work on other projects and 1 or 2 joining Team A. So Team B will be working on issues from Backlog 1 and Backlog 2 right away. When Backlog 2 is done and that team disbands, the couple of folks staying on the project would become part of Team A and continue to help with Backlog 1 issues.

Jim

[Phill Fox]

Jim,

So from this information when team 2 is disbanded the following will happen.

Overall velocity will reduce (due to less team members)
Velocity of Team A will increase.
Therefore you would expect the  calculated end date to be falsely reported immediately after the disbanding of team B, as it will still report based on the previous velocity.

Phill 

[Jim Constant]

Hi Phil,

Here's what I think I'm going to try and I'd be interested in what you think will happen:

Backlog 1: Contains the stories Team 1 and Team 2 will both work on

Backlog 2: Contains stories that only Team 2 will work on

Board 1: This board filter gets all issues where project = Backlog 1 project. I have a Quick Filters for each team that will filter based on the Team assigned to each issue. This is the one I intend to rely on for reporting of the work completed on the Backlog 1 project each sprint.

Board 2: This board filter will get all issues IN (Backlog 1 project, Backlog 2 project) AND Team = Team 2

We'll start and end the sprints at the same time for both teams. I'd expect that Board 1 would work pretty much as it does today. But I'd expect Board 2, which Team 2 would use, would show stories from Backlog 1 and Backlog 2, each grouped together by their respective sprints (but with only 1 Start Sprint button)

But I'm unsure what to expect if I start a sprint on Board 2 which has stories from two different backlogs on it. I'm particularly unsure what JIRA will do with the stories from Backlog 1.

Any predictions you can offer?

Thanks,

Jim

[Phill Fox]

Hi Jim

Apologies for missing your reply to my earlier comment. I wonder how you got on and whether Team B has now disbanded? 

Phill