1

Before we migrated from TFS 2013 to TFS 2018, our workitems were sorted/priorized by a Product Owner with a custom work item field, which held a value between 1 and 10000+, where 1 is the most important to 10000+ which is not important at all. We added the custom field to the work item templates, so the PO was able to modify it directly inside an item, giving it a proper value.

Right now, after we moved to TFS 2018, the backlog is by default sorted using a system-calculated field "order". The field can be changed in the backlog-list (in the tfs web-view) using drag & drop or rightclick -> move to position.

The problem we have now is that our product owners get emails with "I created bug with number 12345. Please priorize it" and the product owner isn't able to directly priorize it higher / lower inside the work item detail page. Instead he always has to open the whole backlog, scroll all the way down to find the item somewhere between the freshly created items. This is pretty annoying and I don't know, what other way there is.

Can anyone tell us, how this is done properly? Is there a problem with the workflow itself?

I haven't found a better site to post this to, so please move this, if there is a better place to ask...

Martijn Pieters
  • 1,048,767
  • 296
  • 4,058
  • 3,343
Jannik
  • 2,310
  • 6
  • 32
  • 61

1 Answers1

0

The field is still there (Backlog Order), but it's hidden by default. You can add it back to the form and 0 should put it at the top again.

There are a couple of Work Item Form Extensions that add simple macro functionality to the work item form. The "One Click Work Item Actions" is one, you could use this to add a "move to top" action to the work item (basically setting the "Backlog Priority" field).

I'm not sure whether there is a better workflow. In the past I've created a special iteration for "new items" which is used in a sort of triage event. Only new items would be in that iteration and from there we'd move the items back to the actual backlog.

From a Scrum perspective, the trick is to have just enough items on the backlog so that it's not a big hassle to move items around. If there are so many items that ordering is a chore, it would make sense to "prune the product tree" and make some deliberate choices about what to keep on the backlog and what to move to a separate bucket of unordered items.

jessehouwing
  • 106,458
  • 22
  • 256
  • 341
  • 1
    See also: https://blogs.msdn.microsoft.com/devops/2014/07/08/where-is-the-field-on-the-work-item-form-to-order-the-backlog/ – jessehouwing Nov 05 '18 at 16:07
  • To let you know, we currently have 1400 open work items. Question: If we reenable the Backlog Order and use it to reorder it inside an individual work item, will automaticle adjust the other items around the new item aswell? So when I move it from 5 to 3, will it modify item 3 to order 4 and nr 4 to nr 5? – Jannik Nov 05 '18 at 16:09
  • It will constantly create random numbers for the backlog order, so that won't work. It's only easy to move to top (0) it's impossible to predict the other numbers. The field is re-calculated automatically. – jessehouwing Nov 05 '18 at 16:15
  • 1400 sounds like a good time to perform some clean-up, how many items are you actually able to move in 3-4 sprints? That's about as much work as you'd want on the backlog. The rest of the work is just "far away". – jessehouwing Nov 05 '18 at 16:16
  • Thats a problem. Lets say our product owner wants to priorize it to "lets do it the sprint after next sprint sprint, he wants to priorize it to something like 25 or similar. That wouldn't be possible with "Backlog order" then. – Jannik Nov 05 '18 at 16:37
  • I'm agreeing with "Just far away", but where to move them to. We wouldn't dare deleting them just keeping 100 or less. – Jannik Nov 05 '18 at 16:40
  • Just put them in a separate iteration and don't select it in the team settings. – jessehouwing Nov 05 '18 at 18:18
  • I'm sorry this is gertting so long, but that doesn't feel right either. Whenever the PO does need to reestimate the "not so important" stuff, they would have to change their Team? It is weird to have teams like "Product Owners" and "Product Owners (not so important)", that cannot be the intended way, can it? – Jannik Nov 06 '18 at 08:03