Behind the scenes: the Backlog Priority or Stack Rank field

Behind the scenes: the Backlog Priority or Stack Rank field

Rate This
  • Comments 69

The backlog in TFS is an ordered list of work items, such as the product backlog. In Scrum you get the ordered list of PBIs and Bugs, in Agile you will see User Stories and CMMI contains the Requirements and Change Requests. The order of the backlog items is dictated by the the “Order” field as defined in the process configuration. The process templates that we ship use different fields for this “Order” field. The Scrum template uses the field called “Backlog Priority”, while the Agile and CMMI templates use the field called “Stack Rank”.

In the screenshot below (which is taken from Visual Studio Online) you see a product backlog that is based on the Scrum template. As you can see in the Backlog Priority field, the values are not from 1..N. In this blog post, I want to explain why it is not consecutive and what is changed in TFS 2013 Update 2.




Imagine we had used a consecutive range of values of 1..N, then moving Item #1 to position 4 would mean that not only #1 needs to be updated, but #2, #3 and #4 as well. Roughly the reorder operation gets 4 times as slow. And imagine that you move #1 to position #200 or even further down.

When we shipped TFS 2012, the product would set the Backlog Priority field to a value to create big gaps, so many items can be added to the backlog (or reordered) without updating any other backlog item. Prior to TFS 2013 Update 2 we used the upper limit of the range of 1,000,000, and used an halving logic to create the big gaps. The first item on the backlog would get the value 500,000, the second item (assume it goes to the top of the backlog) 250,000 and so on. When you continue adding items to the top of the backlog, you would get to a Backlog Priority of 1 for the 20th item. When the user now adds or moves an item to the top of the backlog, multiple items need to be updated to create unique Backlog Priority field values (we only use whole numbers). We anticipated this scenario, and included a feature we call “sparsification”. This sparsification logic starts with the current item and walks down until it finds a gap. All the items in that range are then redistributed to create gaps for new backlog items without affecting others.

When we reviewed the sparsification logic with metrics that we capture on Visual Studio Online and our internal servers, it became clear that the logic was not very effective with how people interact with the backlog. The picture below shows the distribution of the items on our internal Pioneer server (VSO showed similar results). On the chart you can clearly see the spikes on the ‘halved’ numbers such as 500,000 and 250,000. But what is even more important is the ‘dust in the corners’. The top and the bottom of the backlog it is very dense. The result is that the sparsification runs often causing slower performance while working with the backlog. We have had reports where every reorder on the backlogs took over 10 seconds due to this behavior.



In Update 2 we have made modifications to fix this:

  1. Increased the upper bound of the range to 2 billion
  2. Optimized the scanning for gaps when the sparsification runs, which results in less runs of the sparsification
  3. Optimized the logic to generate the new number (as opposed to the halving logic) to make better use of the available gaps

After we shipped the change, we have received multiple reports from customers who were confused with the change. If the customer had set the Backlog Priority field via Excel to values 1..N, the old sparsification logic kept the range values pretty much intact (especially the top items). With Update 2 however, once you add or reorder items on the backlog, the sparsification logic sets the field values to big numbers to introduce big gaps, and give you good performance.This change is intentionally, and by design. The Backlog Priority field was always intended to be a system field, and our recommendation is to not update field manually.

You can still use Excel to quickly set the order of the backlog with the values 1..N, but be aware that the sparsification will kick in. And although the values are different, the order of the items on the backlog are still the same!

Hopefully I have been able to give you more insight in the inner workings of the backlog, and you understand better what is going on.

Ewald Hofman

TFS Program Manager

Leave a Comment
  • Please add 1 and 5 and type the answer here:
  • Post
  • Thank you for the detailed information.  This is very helpful. not to mention interesting.  My team has a very large product backlog that is constantly growing.  What is the most efficient way to manage the changing order?  We are currently dragging the PBIs up and down through the backlog which seems a bit cumbersome.  What is your recommendation?  

  • Amy,

    There are two approaches to your question.

    The first is how to order within a long backlog. If you need to move an item way up or way down, then you can use intermediate steps (pick up an item, and place it near the top of the page, scroll up, and pick it up again, and so on). Or while you are dragging the backlog item, you can wiggle your mouse near the top (or bottom) of the page to speed up the scrolling of the page.

    The second approach - which would be my recommendation - is to either clean up your backlog or split your backlog into multiple backlogs. A backlog with 100s to 1000s of items is hard to manage. Joel Spolsky has a nice blog post on this topic: I believe that an healthy backlog contains the work for the next 3-6 months. You can use the Portfolio backlogs (Features in the out of the box templates) to capture work that is further out.

    Let me know if this helps you.


  • Thanks Ewald, I just had one user of mine that complained about this change after upgrading. Agree that some form of splitting/grouping backlog items (buckets) is needed when the number grows beyond a certain number.

  • The work around that is provided below isn't acceptable nor is multiple backlogs.   A feature that was useful prior has now been removed, with no alternative given.   If the backlog priority was never meant to be used why is it it is one of the few fields directly editable in the PBI itself?  Why is it also the only column that I can current sort ascending and descending order in the web view?  

    At least suggest using "Business Value" so that we can have back the functionality that was taken away.  

    Multiple backlogs is a terrible idea, is against some of the core fundamentals of Agile and takes things back to a cause-effect relationship common to a waterfall methodology.

    Give back some semblance of this end-user functionality by providing at least 1 ascending/descending sortable column.   The "solutions" I'm seeing here are not good ones, and cripple the User experience of the tool.

    I'm not going to be nice about this and accept this as the way it is - this is an expensive product with massive amounts of end user interactions that allow people to do their jobs better, to work with teams better, and to interface and interact with clients - to pull a feature from the user interface without an actual work around isn't good practice.

  • @Ryan Finco - I wonder if Ewald is suggesting the Scaled Agile Framework (SAFe) approach; a backlog of backlogs system.  If you're not familiar with it, I suggest giving it a look.

    @Ewald - Thank you for the additional background information.  We had a lot of users wondering what happened.

  • I have seen the sparsification process with this update cause issues where PBIs can be moved in the backlog from their intended order.  When I edit a PBI, and someone else does something to cause the sparsification process to trigger, the PBI I then save is now possibly between two different PBIs from where it was before because it saves with the backlog priority it was opened with and when the numbers changing behind it, it is possible for it to get moved because of new sparsification process.  I believe this could have happened with the old system, but because of the way that one worked, it never seemed to.  

    Looking at your chart, I am not sure what the problem you were trying to solve was.  I can see the spikes, but so what.  I have seen in the old system PBIs with the same backlog priority and they still seemed to stay in the order they were left in.

  • @Ryan, thanks for your honest feedback.

    You have many questions in your comment. I will try to address them all, but please let me know if you think I missed something.

    1. I assume that your comment that "the work around is not acceptable" is related to changing the position of a PBI on the backlog. Would a context menu item to move an item to the top or to a specific position help to remove your concern?

    2. You indicate that having multiple isolated backlogs is not a good practice and that it brings us back to Waterfall. I am curious why you think that having multiple backlogs in a system is Waterfall. If you look at SAFe for example, each feature team has its own backlog. Do you think that is a bad practice? Or did I misread your comment?

    3. Why would like to sort your backlog on any field? How would you use it?

    4. Your feedback that it is confusing to have the field on the form, and that we change the value underneath you is completely fair. We had the field on the form for various reasons (keyboard accessibility was one of them), but we have addressed all of them in the current version of the product. We have plans to remove the field from the form. Would that remove your concern?

    I am always looking for opportunities to improve the product, and thus always looking for feedback from our customers. Would you like to schedule a meeting with me to talk how you think we can improve the product. If so, please let me know in the comment and we'll set something up.



  • @David, we responded to telemetry results in our backlog. We have seen that the reordering of the backlog could take up multiple seconds as soon as you have a consecutive range in the top of your backlog.

    Imagine that the team ordered the PBIs from 1 to 100. Then every time you move the item on position 50 to position 1, it had to update 50 PBIs. The old logic did not repair the range, so the team was now basically stuck at this performance until they manually created gaps in the backlog ordering field.

    If you change the position of a PBI by drag/drop, it will respect the correct position, even when the sparsification is running.

    Since we don't recommend to set the field manually, we are planning to remove the field from the form. But I want to make sure that I understand where our customers use the field for in the current version. What majority of our customers indicated that they used it to quickly put an item to the top or to a specific position. The other use case is to quickly set the order of a range of PBIs in Excel.

    Do you have another use case for this field?


  • Just to add my 2c's on ordering a large backlog... My team has a backlog with ~300 items at present (due to the way contractual requirements have been added to TFS - there's no easy way out by making it smaller).

    I either use "Alt+Up/Down" to move items up and down the backlog, this sometimes works, sometimes it just ignores me when I let go after a long re-order - it's a tad annoying.

    The other is to zoom out as much as my screen can take it, and drag drop things up/down the list.

    Ewald, I think I'd like to see faster scrolling and the top/bottom of the page, and maybe Multi-Select for when a bunch of items get's added and need moving together.

  • @Dave, if there were a context menu with "Move to top" and "Move to position" be an alternative that would help you to change the order of items over longer distances?

  • @Ewald, I considered it when I first saw your post, and it probably would be helpful, especially when people place new things at the bottom of the backlog. In my current situation (which I appreciate is not ideal) multi-select and faster scrolling would have saved the day.

  • My problem is not with the dragging and dropping of the PBIs, it is more the fact that I open a PBI with a number of say 1000 and when I save it, it saves 1000.  Now where 1000 is in relation to the overall backlog is anyone's guess when I save it.  It was in between 900 and 1100 when I started editing it, but while I was editing it, BOB moved one and all of the sudden 900 is now 500 and 1100 is now 600 and my PBI has moved down in the list by 4 or 5 PBIs.  Most of the time in my example, the PBI I was editing moves towards the beginning of the list not farther down, but I have seen it go both ways depending on where the new PBI falls.

    I am not sure when the new system gets triggered, but when I look at it, it almost looks like it is trying to keep them all at some relative position by renumbering them all with some big range in between and it tries to split the total range by the number of PBIs and it almost looks like it renumbers the whole range every time a new item is added.  It could just look like that to me as I only see the list from my point of view and do not see all of the other interactions from the other members of my team.

  • @David Parvin, when you update a product backlog item, then we only save the fields that you have changed. If you don't change the backlog priority field, then the order of the item on the backlog stays the same, even if somebody else re-ordered the item on the backlog.

    To you point when the sparsification is triggered: it is being executed when there is no gap between the items where you drop it (so that the backlog has to update more than 1 item). The logic that the sparsification applies is not straight forward, but it shouldn't matter. What matters is that the sparsification optimizes the items that it updates by creating big enough gaps so you can experience a good performance on reordering the backlog.

  • Why can't there just be a numeric field that allows for duplicates for end users to utilize as they see fit - e.g. sorting and ordering? We could then use the product the way we want instead of the way TFS is forcing us to work. It seems like you put a ton of work only to create something worse than what we had.

  • How should we set the priority order of PBIs then? If I set an specific order on which PBIs should be addressed, and here I am reading that we don't have a consistent way to keep that order, what do I need to do? What field should I use to have a prioritized list of items that doesn't change unless "I" change it? I am using Stack Rank field to order my priorities, and I even can set to different items with the same priority within the same backlog but for different developer; e.g. Card 3333 with a Stack Rank of 50 and Card 3343 with the same stack rank. Anyway, that was working until someone in the team, triggered this "sparsification" process you are describing, by adding a new PBI, but just some of my PBI's Stack Ranks changed. This doesn't work for me or my team. I need a "stable" mechanism/strategy that respects what I set. I used PSP/TSP, and I do not understand why TFS just rules out what I define.

Page 1 of 5 (69 items) 12345