How to label an enterprise's delivery Jira ticket - jira

To enable an easy progress-oriented view of the delivery to enterprise clients, some tags and labels should be set to each relevant Jira ticket.
How a commitment to an enterprise client should be labeled in Jira?

Add the enterprise delivery label: i.e: SG_delivery
If it is a commitment that is part of the original SOW, Check the 'high integrity commitment checkbox, and add the relevant commitment deadline.
If it is a new functional requirement, add the new_FR label.
Update the priority field, the highest will be a 'must-have'
(5.) After the request will be approved by the product managers they will add the relevant fixed version. i.e. 'post phase 1 depots' to show that the ticket is part of the project scope. They will also add the 'fixed version' of the quarter that the ticket will be released in.

Related

New field under Azure DevOps (VSTS/TFS) iteration capacity tab

I am looking for a method to customize the capacity tab to include new field for each team member where i can specify the buffer time for each one during the sprint.
Is it possible to add such new field entry under capacity tab or not?
This isn't possible right now. You can help upvote this to increase visibility of this need to the product team in developer community: https://developercommunity.visualstudio.com/idea/365553/vsts-custom-team-capacity-activity-as-well-as-cust.html

Is there a way to show commits on subtasks of stories in a Jira scrum board?

We are migrating from an in-house tool to Jira for managing our scrum board, and we have concerns that I have been unable to resolve by searching the Internet. But you folks are smart, right? ;-)
Our current scrum board shows the usual swim lanes across state columns (for todo, progress, review, done). Each swim lane represents a user story, and has a link to (and a snippet of) the user story description in Jira. It also has a number of 'tickets' (these would be subtasks in Jira lingo) that start in 'todo' and move across to eventually end up in 'done'.
So far, Jira can do all of this, too (although creating sub-tasks is rather a lot more work in Jira than in our in-house tool). However:
When we commit code, we include a ticket ID in the commit message, and thus each ticket displays a list of commits that were done to complete that particular ticket / partial story. I haven't been able to find out how to do this in Jira -- if it's possible at all. Instead, it seems one must open a sub-task to see if there are any commits on it?
Each commit also shows its review state, which gives us an excellent overview of how close to done a ticket really is. I haven't been able to find out how to do this in Jira -- if it's possible at all. Instead, it seems one must open the sub-task, and drill down further into Fisheye(?) in order to see the review state?
In total, our tool provides a one-screen overview of the state of each user story, ticket, commit, and review state; and it's very lightweight to pull in new stories (from Jira) and add tickets. We fear that Jira is not able to provide such a one-screen overview, forcing us to open Fisheye in order to know whether a given commit has passed review.
Is it really true that Jira must be this cumbersome?
For reference, here is what a single ticket (subtask) looks like in our system:
And if you look at the whole scrum board, it's actually quite easy to get a feel for the number of commits on individual user stories and tickets, and the ratio of pending/passed/failed code reviews:
I agree with your fears when you say
We fear that Jira is not able to provide such a one-screen overview
In my experience (7+ years with Jira/Agile) I've not seen a such condensed view of information about a sigle user story even on a swimlane with relative cards.
Also in the Atlassian marketplace there seems to be no good plugin to solve your issue, even partially.
To make such move from your in-house tool to Jira retaining all you have there, I fear you should develop a custom Plug-in using Jira SDK to integrate with the agile boards.
It may be enough to start by developing a custom field to show what you need from a "ticket" (ie sub-issue) and trying to insert it into one of the three "slots" available for cards (I mean Rapidboard card layout configuration screen).
If you wanna try, start from here.
Another option to create a new custom field would be the Adaptavist Scriptrunner plugin. It will ease the building of custom fields: your new field can be written also in Groovy rather than plain Java. I've used it to build an extended status custom field (just to give the user an immediate big picture of it) that informs him in plain english and with stylish css colors why an issue is blocked or anything else relevant, getting data from other fields or linked issues that are not immediately visible to the user. IMHO, it is very similar to your problem.

TFS2015: what rights in a collection does a release approver need?

TFS2015 u2. I'm editing a release definition, assigning approvers for an environment.
I have several server-level groups. When I start typing group names in the "Specific users" box on the Approvals page of environment properties, one of them ("Application Hosting Team") comes up, another ("QA Team") doesn't. The former is a part of collection admins, the latter has no specific rights. If I grant the QA team collection admin, it comes up, too.
Question - which rights do I have to grant (short of admin) so that TFS considers it eligible for approving releases? Preferably on collection level.
EDIT: Adding the server level group to "Project Readers" will do, but I'd hate to go through all the projects...
Found two collection level ways:
Create a collection level group, add server level group to that one, grant Allow for Edit collection level items
Add the server group to "Release Management Service Accounts"
Either works. The former is slightly more work, the latter might grant more rights than strictly necessary to approve releases.

How to assign a ticket to a user based on the priority of the ticket in JIRA?

I have a requirement on a project that a ticket which is a Blocker should be assigned to ABC user, ticket which is a Major should be assigned to DEF user, so on.
Has anyone implemented a worfklow in JIRA which does something like this? I know you can design a workflow which can assign a ticket to the user based on the type of the ticket but based on the priority can you assign a ticket to a user? Please help.
JIRA comes with components and component leads, and if you leave the assignee at Automatic then the newly created issue will be assigned to the appropriate component lead. I'm not sure what you mean when you say that JIRA can assign based on issue type.
Assigning according to Priority means that you have to trust the person setting the priority. Also, you have to be able to configure the mapping from Priority to Assignee somewhere and then be able to change that mapping later on.
To assign according to priority I would use a custom Script Runner post function on the create transition of the workflow in use.

Different start status for some ticket types

I'm setting up an advanced workflow in Jira and I have some ticket types that I'd like to automatically be transitioned to a specific status upon creation.
Normally our tickets start in the backlog, and then go through some status to get to "Ready for Development" and then some picks that ticket and transitions it to "In Development".
What I would like is for some ticket types to automatically get to "Ready for Development" or "In Development" when they are created.
This would be relevant for tickets representing a backport of a feature or bug fix to a previous version, or an issue ticket for another blocked ticket.
You have to copy the current workflow to another and in the new one to change the "Create Issue" transition to point to the "Ready for Development" step. Then in the workflow scheme assign the new workflow to the issue type representing this different kind of ticket. The drawback here is that you'll have to support two workflows instead of one, but I can't think of better solution.
You could also get more complex and use the Script Runner add-on and automatic transitions as noted at http://blogs.onresolve.com/2011/04/auto-transitions-in-jira-workflows/

Resources