Please HELP, how can I customize a request number according to its request type?

[Mela]

We have 3 different types of requests: 

1.) Service Request

2.) Incident Request

3.) Problem Management Request

My plan is to customize their own request number like these

1.) Service Request - SR0001

2.) Incident Request -IR0001

3.) Problem Management Request - PM0001

How can I possible do this? Please Help

[Nic Brough -Adaptavist- · Accepted solution]

It is possible to get close to this, but not quite 100% there, and you probably won't want to implement it this way as it fragments your issue tracking.

A Jira issue key is always formatted as <ABC>-<XYZ>.  The ABC is the project the issue belongs to, and the XYZ is a numeric sequence.  So the "not quite" bit is that you can't have keys without a hyphen or with leading zeroes.  SR0001, IR0001, and PM0001 will be SR-1, IR-1 and PM-1. (I'm guessing your desire for your format comes out of having used a legacy tracking system which uses it.  If so, you should examine that - is it really of any good use for your humans?)

The bit you probably don't want to do is the projects - you can lead each key with a different piece of text, but you can only do it by having separate projects.  For your text, you'll need three projects, one for service requests (key SR), one for Incidents (key IR) and another for Problems (key PM)

[Fabio Racobaldo _Herzum_]

Hi @Mela ,

unfortunately you can't change issue key in JIRA. it is the aggregation on Project Key - ticket number within your project.

Keep in mind, that if you have another project with the same request types, the same number could be not unique in your instance.

Hope this helps,

Fabio

[W]

This is nightmarish... considering you forbidden the users from imparting custom sort orders on EPIC children, it means that when you create the children, you MUST create them in the order they are going to be worked or you have highly inefficient work processes.

Say an EPIC has 20 children, say backend and frontend and testing and infrastructure all create their EPIC children independently... step 2 is for a project manager, or scrum master if you insist, to sequence the tasks. One can go and put blockers, that should hopefully stop people from starting something they shouldn't... but you have to click into each of the 20 children to find what is workable.

In the end, devs need an ordered list of things to work and trust in the automation and manually processes people work to put them together... Jira by omission and preferences, does not provide the ability to achieve it.

Hence, now we are trying to swap ticket numbers to get a reasonable order on an EPIC child list. Can't even save the setting for default sort order. It's really unbelievable, the primary workflow management approach in a workflow management tool is effectively unusable if you care about efficiency of your staff.

[W]

Even worse, you do allow reordering of subtasks on stories.... my assumption is that the decision to do it one place but not the other was not intentional. Seems completely arbitrary, not giving me much confidence in the tool... reporting rarely works to boot.

[Nic Brough -Adaptavist-]

All of this seems like you have not quite grasped what Agile is for (and Epics within it).  You're still thinking in a Waterfall manner where you plan at the top level (Epic), and then try to chop it up into pieces to be allocated out.

In Agile, your product manager works with the customers to find out the various things they want or need, and creates appropriate stories.  When you realise you've got related stories and themes starting to emerge from these conversations, you attach them to Epics.  Of course, you need to bear in mind that the stories may change, and more will continue to be added as the teams explore the work.

Jira Software supports Scrum and Kanban.  Scrum has a backlog, where your teams rank the stories according to what needs doing next (and you can enable one for Kanban if it might be useful)

I would not recommend trying to use Jira Software for Waterfall, it's just not built for it.  But if you need inflict it on your teams, you can do it - just take away all their autonomy in a Scrum project, so that they cannot rank.  That's not going to fix your "ordering by numbers" problem, but that's a less than ideal way to organise any project anyway, it's better to rank things.

Subtasks are wholly a part of their owning issue, and can be re-ordered in the issue view, but because they're fragments, their order isn't too important to an Agile team - the team understands all the dependencies in their already.

[W]

I mean, my friend, both agile and waterfall are extremes, two massively far apart areas of a contiguous spectrum. Neither exists 100% in any regard in the rigidly defined way you are implying, at least not in a functional company. Agile is not the first, nor will it be the last, attempt to teach basic project management and software lifecycle development to folks who just write code. The inherent tradeoff between the spectrum of agile and waterfall when designing a workflow and software lifecycle for any given project, in any given environment, is certainty vs. agility. Yes the web world needs agility over certainty, the winning business is often just that because they were the first. That being said, these tradeoffs are nothing new. In fact, the inventor of agile regrets it; I get the impression that it's been used as a excuse, when it was only really intended for illustrative purposes in teaching the basics, just as waterfall was. No practical approach to managing work is pure waterfall, when building a fighter jet, there are revisions.... it's more like a predefined water system with valves and recirculation... one cannot ignore the sequence of work needed to build a doctors website for monitoring a pace maker by quote the very very basic of agile. Agile is not so complete my friend, one cannot ignore the things we've needed as human beings to complete projects the last 10k years of civilization just because we are in a new field, there are things fundamental to all projects, sequencing work is most certainly one.

If you disagree, please justify, using the agile philosophy, why I am allowed to sequence subtasks on a story, but not children on an epic?

As far as I can tell, this is an accident... ironically, caused by using agile as an excuse not to ensure consistently across interfaces.

All IMHO.

[Nic Brough -Adaptavist-]

You are allowed to sequence them.   The problem is that you're adopting a clunky, slow, and non-responsive way to do it.

Use ranking, use links to establish the blockers / dependencies / order, os subtasks to indicate bits of story that need doing. 

Sequencing is the wrong approach, in every case.  I can't think of an approach that works with sequencing.   The most obvious example:  I've created 15 stories.  As the project progresses, we realise there's a problem that needs a new story.  So we create #16.  But #12 needs it doing earlier.  Sequencing here has failed.

[W]

What's "ranking", is that the priority field? Priority, cost, time to complete, predecessors... these all go into determining what order tasks MUST be worked in... some can go in parallel, others cannot, one cannot build a foundation after they build they roof.

I really do not know what your talking about, your making an assumption that a sequence of past, present and future events must remain static at all times Your making an assumption that plans, task sequences, parts lists, purchasing requisitions, ER diagrams, Reports and scientific studies (or spikes if you insist) and everything traditionally needed to manage software MUST be static from the initial conception. This is ridiculous and false. Plans change, change requests happen, sometimes they get out of hand, but never if managed correctly. Claiming sequencing tasks across disparate departments (e.g. testing, front, back, ETL, infra, DB, PDF service, devops, etc) and potentially across many cycles (or sprints if you insist) is unnecessary or a bad approach is the craziest thing I've ever heard, but I hear this stuff all the time from the people who follow agile like a religion and think of waterfall as the devil... it's just as insane as believe the same for red and blue. A comprehensive explanation of agile can fit on a page, waterfall is even less, one cannot manage a company with a page. I think the proof is in the fact that there is, in fact, no real agile workflow in existence, nor waterfall... look at trello, look at jira, look at monday (not really agile, but easily to build agile into it), look at you track... they all claim to be agile, yet the solutions couldn't be more different.

I think you have a false misconception that waterfall and agile are different things, and that they are rigid as steel. This is not the case, both are two sides to the same coin, just as red and green are two areas of the same spectrum... a spectrum doesn't actually exist in reality, its a human construction to help us function and understand, the same is true for agile and waterfall.

I also think your making the common mistake of thinking that agile is a complete project management philosophy, it isn't even close. Agile was meant as an encouragement solely for web based developers to give their lifecycles more agility, as needed in the web world, just as waterfall was in solely as a means to teach professional engineers that mistakes happen, things get missed, sometimes you have to backup and reassess; this is just reality, and no matter how much you religiously believe in agile and shun waterfall, reality always catches up to you.

It is not used much at all outside software, and its completely unnecessary and counterproductive if writing software any thing else outside of browser/server software on the web... like assembly, VHDL, even certain desktop apps.

I think it's also seriously false assumption to think that any given software like jira or trello has actually successfully implemented the rigid agile workflow you think exists, I think of as just an illustration. In the end, decisions need to be made... do I create a spike or just spend a couple hours planning an epic... do I need an epic with children (and forbidden reordering/sequencing for no stated reason) or do I need a story with subtasks (and allowed reordering/sequencing for no stated reason)... how about when I'm in trello, or zendesk (the origin of many jira tickets). How about when you have 200 people doing it?

Waving the Agile flag everytime someone states the most basic need in managing a project I find to be crazy... I only get this during projects on the web... could you imagine building a house, watching them construct the roof before the foundation, asking them how they are going to finish the house and them saying, "it doesn't mater, we have stories we meet on every morning with a scrum master, priority is set and the user cares more about not getting rained on then the concrete under the carpet, so the roof is priority one". Granted, maybe there should have been a blocker... but I think it's also granted Jira shouldn't allow a task to start until the blocker is cleared.

Again... I have an EPIC with 20 stories related to a giant feature... at present, the stories are shown in creation order... I am also allowed to resort these by priority and other things, but this cannot even be saved, and I cannot sort in the order they need to be worked which so clearly obviously ideal, so devs don't have to open every one to find ones without blockers.

What I need is obvious, been doing this for 20 years, agile, waterfall and everything in-between... what I hear now I hear often... someone stating a simple and justifiable need (as justified here in), and receiving a belief based unjustified response effectively using agile as an excuse not to solve or justify existing design.

I believe firmly that a good software engineer has the skills to meet EVERYONE's need in parallel though perhaps in a different way than original requested to make it fit in the larger picture, when designing software for any singular purpose. I believe the same is true for ANY work management software as well, and I believe strongly the support should not continuously brush off improvement requests by using agile as an excuse, without justification or explanation as to why story subtasks can be sequenced while epic children cannot be... this is not covered in agile my friend, provide a reference if wrong please.

I have heard no "why" or no "do this instead" to ensure things are worked in a reasonably efficient order.... and "all hail agile" certainly doesn't cut it.

[Nic Brough -Adaptavist-]

Hmm, this is quite a long essay, I'll try to pull out the pertinent points:

>What's "ranking", is that the priority field?

No.  Ranking is putting issues in the order of importance to the team.  Priority can feed into is, as can customer feedback, timing, estimates, capacity, dependencies, and so on, but the rank is simple list of issues that need doing, ranked first to last.  It is one of the ways you do sequencing in any software, not just Jira.

>I really do not know what your talking about, your making an assumption that a sequence of past, present and future events must remain static at all times

Er, that's what you said, not me.  You are the one trying to use an issue key as a sequence.  It really is not for that.

>I think you have a false misconception that waterfall and agile are different things,

No, it's the opposite of that.  They are very very different.

>I also think your making the common mistake of thinking that agile is a complete project management philosophy

Absolutely not.  It's not a project management "philosophy", it's an approach.

>Agile was meant as an encouragement solely for web based developers

No, it was not.

>It is not used much at all outside software,

You'd be surprised at how wrong that statement is.

> Waving the Agile flag everytime someone states the most basic need in managing a project I find to be crazy.

It is, you need to be looking at the nature of the project and deciding what methods to use.

> Could you imagine building a house, watching them construct the roof before the foundation

Yes, that's actually one of the examples I regularly use when explaining that being Agile does not mean doing that.  In fact, Waterfall makes that mistake a lot more.   With Agile, the worst case is that your dev team takes one look at the tasks, reports "oh don't be silly" and ranks the foundation higher in the to-do list.  

Waterfall fails on that - the plan says we build the roof first, so we have to.

>Again... I have an EPIC with 20 stories related to a giant feature... at present, the stories are shown in creation order... I am also allowed to resort these by priority and other things, but this cannot even be saved, and I cannot sort in the order they need to be worked which so clearly obviously ideal, so devs don't have to open every one to find ones without blockers.

So be Agile - rank them as needed, not as you define them.  The whole point of Agile is that things change and you adapt.  There's a constant re-ranking happening.

>What I need is obvious, been doing this for 20 years, agile, waterfall and everything in-between...

If you've not heard of ranking, then I'm afraid I have to doubt the accuracy of this statement.

[W]

Interesting, couldn't disagree more with this or your analysis, giving partial quotes of mine to warp the intent.

Bottom line, agile and waterfall are Two extremes and extremes never work in reality. If your building say the great pyramid of Egypt thousands of years ago, waterfall is sort of the only "approach" as you say or I say "project management philosophy". That doesn't meet you just keep building if you screw up, you gotta backup and try again. Thus even in its most pure form waterfall never actually existed, it's more like a water system. I've only ever seen agile in the web world, been an engineer for 20 years.

Bottom line, I've used jira a lot in my career, for probably 50 different clients, smallest client was maybe 10k employees, except my current is about 300. Never once have I seen jira implemented with a rank field, let alone a view where it's sorted as such, more often then not i see jira misconfigured, i actually saw one huge company with 75 different ticket statuses, things like in-progress, working, Working, In-Progress, 1-open, 2-working, and others. More often than not, i see jira as a hinderance to my work more that a help, and I'm tired of asking for support and getting agile thrown in my face from Atlassian.

And regardless, I still don't understand why I can sequence subtasks by dragging them, but not children on an epic. You claim this is the agile way, I say it's probably unintentional, Two people or groups working on the same frontend features for slightly different data without the same requirements. Maybe rank is being set when I drag a subtasks, no idea, don't have the field... but I'll talk to the department in charge of jira and see if they know anything about rank.

[Nic Brough -Adaptavist-]

You've used Jira and Agile a lot and never heard of ranking?

I'm sorry, but that makes absolutely no sense, unless, for some reason, you've never used a board, a backlog, or a support portal.

I don't understand why you're not getting the idea of "put your items in an ordered list" rather than your "I have to enter things in a strict order so I can use the key to do it".

[W]

What are you talking about, an ordered list like:

1. Backend: api routes
2. Frontend: Ajax
3. Database: migration

Or are you talking about the actual jira field rank that is not enabled and which I have no permissions to use?

Ordered lists are used in all our tickets, from spikes to epics.

Backlog we do reorder that list, but that isn't a work list, that's similar to low priority triage, we move things to the top that we need to review as a team.

Your talking it would appear, not about the rank field itself, but by using the active sprint board to ORDER BY rank field. Firstly, I plan tickets for my company, projects that could be 1 to 3 points, or epics that could be 50 points. Sequencing is important when planning new big features, especially when you know what you want to are trying to build. Thus, our scrum master has opted to GROUP BY epic as the active sprint sort order, not order by ranking.

Regardless, sequencing taks in a sprint is a matter of priority and blockers... rank and priority are related and why I see most companies use one or the other not both... usually priority is used, but it's understood better, rank is new only to jira as far as I know. Sequencing the tasks to build software, or even a house, under an epic process is not an unreasonable request.

Again, you haven't explained why I can reorder subtasks on a story but not stories on an epic... all I hear is excuses, workarounds for one of an infinite sea of jiras possible workflow implementations and ignorance about the flexibility and common misconfigurarions of the tool.

I am required to create stories no more than 6 points. When related to a large effort, the must be on an epic. As a matter of policy, to avoid never ending epics as I've seen, I only create stories on epics. Epics are the root of big efforts, not sprints... you might be working 40 stories associated with 15 epics in a sprint. After planning, say 1 story with 5 subtasks, I am able to drag and drop the subtasks around. When the scheduler designs to schedule something, they can see the order they need to schedule things for a story, often across many sprints. This is not true for an epic. Why can I "rank" everywhere except in an epic? Why do you allow sequencing subtasks on a story but not children on an epic. Stop dodging the question.

[Nic Brough -Adaptavist-]

No, we are talking about you trying to order your issues by the wrong thing.

You say "Or are you talking about the actual jira field rank that is not enabled and which I have no permissions to use?" and then go on to talk about boards and backlogs.  

That is a direct contradiction - the backlogs and boards use the rank field for ordering, and call the concept "ranking".  So which is it?  Are you using the rank field or not?

> Regardless, sequencing taks in a sprint is a matter of priority and blockers... rank and priority are related and why I see most companies use one or the other not both

No, it is not.  Sequencing tasks is a matter of ranking them.  It is often driven by data like priority and dependencies (blockers), but it is often a lot more complex than that, and looks at other data.

Most organisations use both ranking and priority, but as you cannot use priority for sequencing (which of the five issues that are "critical" should be first on the list?), the teams will have their sequences set by the ranking.  Priority is just one factor that feeds into how they rank their issues.

>Sequencing the tasks to build software, or even a house, under an epic process is not an unreasonable request.

So create a board that looks at the stories under an Epic and use the board's backlog to rank (sequence) them

>Again, you haven't explained why I can reorder subtasks on a story but not stories on an epic...

Because stories are not part of an Epic.  Stories should be ordered alongside each other, because the teams are likely to have stories outside the current Epic, as well as dependencies.

>I am required to create stories no more than 6 points. 

That's a very waterfall way to do it, not Agile in the slightest - Agile processes would have you write a story, then the team would estimate it, and if it is too big to be dealt with in one sprint, decompose it into several stories which could be.  But if "decompose before writing" is working for you, that's fine.

There is no sequencing on sub-tasks.  There is a display where you can rearrange them within the story of which they are a part if you feel like it, but it's not sequencing or ranking.  Sub-tasks do not really have dependencies or an order other than "getting all of the parent issue done", and they don't have a rank, because the rank is that of their parent issue.

[W]

"Because stories are not part of an Epic.  Stories should be ordered alongside each other, because the teams are likely to have stories outside the current Epic, as well as dependencies."

- finally an answer, and not a good one... the application allows epics to contain children, any ticket type. I limit them to stories and branch off those spikes, subtasks and related blockers with 12 other department projects. Root tickets are important for manageability. We do not work from the backlog board, we work from an Active sprint board... seems to be grouped by epic... like I said, more often then now I see this tool misconfigured.

"There is a display where you can rearrange them within the story of which they are a part if you feel like it"

- fine, why can't I do it on an epic too?

[Nic Brough -Adaptavist-]

Because the stories are not part of an Epic.  The Epic is a pointer to a group of issues that are moving towards the Epic's goal, it is not a container.

And you can rank within an Epic if you really want to.  I already told you how to do it.

[W]

"Because the stories are not part of an Epic."

• Being that every story can only have 1 epic link, and from the epic ticket when you want to make that link the control is called 'link child', I would have to assume the epic is the parent in a 1-to-1 relationship. 

"The Epic is a pointer to a group of issues that are moving towards the Epic's goal"

• Yep... sometimes stories block each other, sometimes things must be worked in an order... sure would be nice to open the epic and see that order

"And you can rank within an Epic if you really want to.  I already told you how to do it."

• I must have missed it, how exactly? It will resort the display within the epic ticket as well?

[Nic Brough -Adaptavist-]

The Epic is in a 1:M relationship, not a 1:1.  It's not there to group dependencies, they may exist outside the current epic, which is one of the reasons they are not a container for issues.  Epics are a grouping, not a plan.

The order of issues within an Epic is not really important to the Epic, the Epic is there to represent a larger goal.  The detail of what needs doing next is done at the issue level (as it is within stories that have had bits factored out into sub-tasks)

Look for "stories under an Epic" in the previous post.

[W]

Your insane. I'm not going to create a board for every project. epic to story is 1-to-1, create a story with 2 epics if I am wrong. As usual, I get zero comprehension from support let a lone solutions. I manage 20 projects across 200 codebases utilizing resources for 1000 people across 50 departments, roughly 40% are highly agile, the rest are highly engineering centered. There are about 150 jira projects, the rest are something else, I have board creation rights to precisely 1, and I would not implement such a solution on any of them. Stories without epic is fine, but the concept of the root is important, sacred, I can't manage 20 projects without hierarchy, and I should see the hierarchy clearly in every view and scale, so that I am focusing on the work not the tool.... this is pointless... good day to you.