nav[aria-label="Primary Navigation"] { padding: 0; & ul { list-style: none; width: 100%; display: flex; flex-direction: row; justify-content: start; align-items: start; gap: 30px; padding: 0; & li { margin: 0; } & ul li { list-style: none; } } }

Can I modify "Send to" section of right-click menu on Backlog view for Scrum boards?

Jira Admin_xyxlgn

I'd like to modify the "Send to" section of the right-click menu on the Backlog view for Scrum boards so that it includes an option to add/remove tickets from sprints without affecting the Rank value.

Currently, when moving tickets between sprints and/or the backlog, the Rank field gets implicitly updated for some reason.

I'd like to be able to easily move tickets between sprints and/or the backlog while preserving the Rank values. The only way to do this currently is to directly edit the Sprint field on each ticket which is time consuming and not intuitive.

I've looked for add-ons or plugins to do this but haven't found any.

My last ditch effort is to create a plugin or add-on that adds this functionality and before I started wanted to know if others had already tried this or if there were impediments to building it.

Thanks and please let me know,

Davin Stewart

Accepted answers

Nic Brough -Adaptavist-

It's because of the way the ranking and sprints are done.

Think of the way you plan a backlog and sprint - you move the things to the top of the backlog to rank them higher, and then, when you create a sprint, you skim off the top X issues at the top of the backlog.

It makes no sense to preserve the rank if you move something in or out of a sprint when you think of it that way - the whole point of ranking is to get a top X issues.

So, I'm afraid that even if you wrote something "that preserves the ranking", it's not going to work, because if the rank remains higher than something in the sprint, the issue needs to remain within the sprint, and hence keep its rank.

All comments

Nic Brough -Adaptavist-

It's because of the way the ranking and sprints are done.

It makes no sense to preserve the rank if you move something in or out of a sprint when you think of it that way - the whole point of ranking is to get a top X issues.

Jira Admin_xyxlgn

Nic, thank you for your response. I appreciate you taking the time to address my question.

However, you didn't answer my question. I'm asking if it's possible to change that drop-down menu. Do you know if it is possible? If so, could you give me some guidance on how to go about it?

As for your argument in favor of how the application currently behaves, in an ideal world I'd agree with you but Rank is not the sole determining factor of what goes into a sprint. For example, tickets be ranked very high on the backlog but not yet eligible for addition to a sprint because it needs because it's waiting for a client to sign a contract, need further clarifications on done criteria, etc.

In this case, let's say that I remove a trivial bug from the current sprint and that the trivial bug was pulled from lower down in the backlog ... in that case it is invalid to say that the trivial bug should have a higher business priority than what is already at the top of the backlog. The business priority should be maintained regardless of whether a ticket is in a sprint or not.

Logically, sprint planning and backlog prioritization are two separate and distinct functions within the agile process. Sprint planning takes backlog prioritization into account when constructing a sprint but does not change the Rank of the tickets. Adding a ticket to a sprint indicates the team is willing to commit to complete that ticket within that timeframe ... that's it. It doesn't change anything about the Rank of the ticket, although Rank was a input during sprint planning.

By automatically changing the Rank of a ticket when it is added into a sprint it disrupts the users ability to manage the business priority of their tickets and undermines the whole agile process. It takes control out of the users hands and programmatically re-sorts their carefully constructed backlog in an order prescripted by Atlassian . This approach removes functionality and flexibility from the system and reduces user satisfaction.

It's also inconsistent behavior from the application. If I edit the Sprint field directly and add a ticket to a sprint that way then the Rank value is unchanged. However, if I right-click on the ticket in the Backlog view and select "Send to" to move it into the sprint then the Rank value is updated to an arbitrary value. This is inconsistent behavior and confusing to the user.

Nic Brough -Adaptavist-

That's a good point, I did not answer the question.

Yes, you can alter these menus, by installing add-ons that insert items into them. The context menu is a difficult one though - for most menus, you can add "web fragments", but I'm not sure that the context menus are done that way. I actually suspect the hardest case may apply, you may have to pull the Software application apart and hack some properties file.

However. My point was mostly that your specification doesn't work. Your follow-up thoughts do make a lot of sense, but they do completely miss the point. Your argument is essentially "I want to ignore how sprint prioritisation is done in Agile Scrum", which in itself is fine, but you can't expect an Agile Scrum tool to even begin to support a totally different process.

If there's one thing I'd pick out, its:
>Logically, sprint planning and backlog prioritization are two separate and distinct functions within the agile process.

Separate yes, but your desire to break them is wrong, and they are strongly related. In an ideal sprint, you prioritise your backlog, then take the top ranking items off the backlog until our capacity is filled. As soon as you stop ranking things with that in mind, you break everything.

Jira Admin_xyxlgn

Thanks for the response Nic I'll look into web fragments.

On the other topic about JIRA design, I appreciate your points but still respectfully disagree.

How specifically does separating sprint planning and backlog prioritization break everything? I honestly don't see any problems with that.

"In an ideal sprint, you prioritise your backlog, then take the top ranking items off the backlog until our capacity is filled."
When you find an ideal sprint please let me know. I've personally never seen one. smile That point aside, though, in my corporate environment the prioritization is typically done by product owner ... who is normally a part of a separate group for product management. They're not a part of the delivery team and so can't commit to items during sprint planning. Their role is to sort the items according to business need.

The delivery team then takes the prioritization as an input during sprint planning and factors in additional items such as grooming status, vacation schedule, technical feasibility, synergy with other items in the backlog, etc to determine what they're willing to commit to.

Essentially, sprint planning is the teams way of saying "These are the highest ranked items that we're willing to commit to delivering in the next sprint". That should not affect the business priority (i.e. ranking) of the tickets, in my opinion.

If we did adjust the rank of tickets during sprint planning then that provides a loophole to the prioritization process that can invalidate the product owners ranking. I've seen firsthand that that can cause problems such as the product owner losing ownership of the prioritization process and missed business goals because tickets were delivered out of business priority order.

In my mind, it's very clear that prioritization should be owned by the product owner and sprint commitment should be owned by the team. There can be exceptions to this, of course, but when we start programmatically changing prioritization based on sprint planning then I've seen problems occur.

This could be very easily supported by Atlassian by simply commenting out the code that updates the Rank field when adding tickets to sprints and by adding an option to move tickets to the backlog without changing their rank.

By doing this simple change, they would increase their products flexibility, provide more control to the user, and make JIRA more intuitive as well.

Welcome!

It looks like you're new here. Sign in or register to get started.

Quick Links

Find more posts tagged with

jira

cloud

jira-software

jira-software-cloud