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,
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.
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.
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.
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. 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.
No, you've really not grasped the reality here. You are making the classic mistake of equating prioritisation with ranking, and then going on to make the false equivalence that "business priority = rank", which is always wrong.
A lot of what you say makes sense at a glance, but fails when you think it through properly.
>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".
This is right. The sprint is the highest ranked items you (think you) can do in the sprint.
>That should not affect the business priority (i.e. ranking) of the tickets, in my opinion.
This is where you are wrong. Business priority is absolutely, unequivocally, NOT ranking. A business priority feeds into your ranking and sprint planning, but it's total rubbish to equate it with ranking. The rank reflects what you need to do next. Nothing to do with priority.
Ok, I see what you're saying now.
What I'm hearing is that you're using Rank to represent the order that tickets will be added to the next sprint during sprint planning ... and this order is after the team has evaluated all of the factors that go into committing to those tickets such as business priority, vacation schedule, etc.
But that raises another problem ... we still need some way to represent that business prioritization in Jira. If we're not using Rank then what can we use? The Priority field is not very granular or convenient to use ... what do you recommend?
Yes, that's using the rank as it's intended to be used, pretty much as defined in all Agile processes.
Business priority can be very nebulous and the best way to do it depends on how your organisation works. Some people might simply have a "business priority" field as a drop-down or text. Some may just use the priority field as is. At the other end of the scale, some people create business requirements as separate issues in a separate project and then rely on product owners to create the stories for development. Or, if you've got too many projects to handle, install Portfolio and manage entire business development plans with it.
Badges are a great way to show off community activity, whether you’re a newbie or a Champion.Learn more
As part of the Bitbucket product team I'm always interested in better understanding what kind of impact the use of our tools have on the way you work. In a recent study we conducted of software devel...
Connect with like-minded Atlassian users at free events near you!Find a group
Connect with like-minded Atlassian users at free events near you!
Unfortunately there are no AUG chapters near you at the moment.Start an AUG
You're one step closer to meeting fellow Atlassian users at your local meet up. Learn more about AUGs