Learn to use Visual Studio, Visual Studio Online, Application Insights and Team
Foundation Server to decrease rework, increase transparency into your application and increase the rate at which
you can ship high quality software throughout the application lifecycle
Whether you've installed the beta or signed up for the hosted service, you've probably seen the new taskboard feature, one of the new planning and tracking tools. Hopefully you've started playing with all these tools, adding items to your backlog, creating tasks, and moving tasks from one state to another. Maybe you've shown your teammates these features, too, and they've started creating tasks of their own.
That's certainly how it happened on my team.
Before I knew it, everyone started creating tasks to track their work in our current sprint, just to test the waters. Which was great! In fact it was fantastic to see everyone so excited about using this new feature to track work. Our management wasn't sorry to see it, either.
Until one day I got a panicked email from one of my teammates:
Help! The taskboard is broken!
I just went to update my tasks, and I couldn't see any tasks at all! I got an error message that said "You have exceeded the number of items allowed on your taskboard." What do I do?
In our enthusiasm, we'd inadvertently overloaded the number of tasks allowed for the current sprint. The default display limit for the taskboard is 500 tasks. That might sound like a lot, but when you're on a team with 20 people and your "test sprint" is measured in months, not weeks (as ours was), you can cross that 500 task limit pretty easily.
Our scrum master could have made us delete tasks from the sprint until we were under the 500 item limit, and for some teams, that might be the right answer. In fact, if you're using the hosted service, deleting tasks until you meet the limit is currently your only super-simple option. You can use the client-side API for accessing the Agile and Common project configurations to change the limit for hosted projects, but that's another blog post.
In our case, our team was (and is) using our own test server, so our solution was simple: modify the process template to increase the limit.
This fix is very easy. All it takes is the witadmin tool and a single line of XML. You'll need to be a project administrator to do this, but as long as you have the required permissions, it's a piece of cake.
All taskbord items are loaded into browser memory, so changing the limit increases the memory demand on your clients, and might cause issues. Because of this, I only increased our team’s limit to 800, and we’ve never needed to increase past that.
4. Save the file and upload the modified process template to your server by using the witadmin importagileprocessconfig command.
That's it! This entire process, from download to edits to upload, took me less than five minutes on our test server.
is there a threshold number for the tasks that can be set?
I increased ours to 1000 and wondering if this is the maximum limit that will definitely cause slowness on the client's machine