TeamCompanion enables Scrum teams to resolve capacity and prioritization issues more efficiently

With TeamCompanion, you can try out different offline capacity and prioritization scenarios before you finally pick the one that best suits your situation.

In order to illustrate how you can easily reassign tasks in unplanned situations with TeamCompanion, we will walk you through a real-life scenario.

Furthermore, this is the first in a series of blog entries about real-life project scenarios. We intent to show how, with the help of TeamCompanion, you can handle different realistic situations you come across every day in your development process.

Offline “What if” Scenario

Adam, the Product Owner, receives an e-mail from Brian, saying that the team members have some additional unplanned absences during the sprint, and that now, two days before the sprint end, they are short of time. This means that they are not going to be able to complete the work that they agreed on at the beginning of the sprint. Due to such unexpected conditions and very tight deadlines, the outcome of the entire project might be compromised. In such circumstances, Adam has to quickly react.

With TeamCompanion, Adam can visualize all related information and therefore quickly and efficiently resolve capacity and prioritization issues.


He takes a look at the Sprint backlog and the corresponding burndown chart to see how the team is progressing. The burndown currently looks fine, meaning that, until this point, the team was doing a good job.


Next, he needs to check the team capacity as announced in the email. Cameron will be absent until the end of the sprint, and he is currently 15 hours overloaded. Brian is absent today only. He also is overloaded, but only by 4 hours. The embedded statistic for team capacity shows that the team has 39 hours of work planned in total until the end of the sprint and that there are only 23 hours available. Adam is forced to make changes to the sprint backlog in order to make it realistic once again.


Adam filters his view of the sprint backlog to show only active tasks and not yet done PBIs. Now, he can see just the remaining active tasks. On the Team pane, he can analyze the remaining capacity chart. As the sprint is near its end, the team has already agreed on who is going to work on the remaining tasks, and therefore all members except Annie are already at capacity or overloaded.

Annie has only 3 free hours left, which is not enough to take over Brian’s and Cameron’s tasks.

The 1st PBI in the list is already fully in progress, so it doesn’t make sense to change it. The 2nd PBI has just partially started. The work on the 3rd PBI needs yet to be started. Adam decides to fully remove the 3rd PBI from the current sprint. He clicks on the Iterations pane in the right hand bar, and drags the 3rd PBI from the sprint backlog list to the product backlog list item in Iterations pane.


All charts and statistics are automatically adjusted. The team capacity statistic now shows that 16 out of 23 hours are needed. So the team now has 7 unassigned hours. That will be their buffer – less than one man day. Annie, Brian and Julia have now 8, 3 and 4 hours left respectively.

In the TFS Web Access, you can check whether adjustments in the project plan are feasible only after committing real work item changes to TFS. This is not the case with TeamCompanion’s agile planning tools! Here, you can use our offline support and inline charts and statistics to analyze different “what-if” scenarios, without actually committing any changes to the server.

As a Product Owner, it’s not up to Adam to assign tasks to team members. He just needs to verify whether the sprint plan is feasible after his changes. He wants to check one of the possible “what-if” scenarios by reassigning tasks in offline mode.


He drags and drops tasks from the sprint backlog list either on the Team pane or on the Members pane in the right hand bar. All changed work items are shown in italic, indicating that these are only local, offline changes, that you can either save to the server or discard (undo).

The plan seems to be feasible once again. All team members even have some spare time left! Adam concludes that this change will help the team successfully finish the sprint with a small adjustment. On the Plan and Prioritize ribbon, he clicks on the Undo button to undo all the changes he made.


Finally, he needs to adjust the sprint backlog once again, by removing the last PBI and let the team assign the remaining tasks as they see fit. So, once again, Adam drags the 3rd PBI from the sprint backlog list to the product backlog list item in the Iterations pane in the right hand bar. On the Plan and Prioritize ribbon, he clicks Save to save only this change. The team will do the rest by themselves.

In this scenario, you saw how Adam, the Product Owner, can easily workout different solutions and pick the one that represents the best solution for a particular project scenario. He will save all changes only after he reaches a feasible solution. In this way, he is able to quickly react and easily adjust the plan in order to bring the team back on track. TeamCompanion guarantees a fast and efficient resolution of prioritization and capacity issues and ensures smooth and continuous flow throughout the entire development process.

Keep an eye on our next scenario!

Note: The examples in this blog are based on the Brian Keller’s Visual Studio 2012 RTM ALM Virtual Machine, which has been upgraded to Office 2013 and expanded with TeamCompanion 5.0. RTM.

What others are saying.

No comments posted yet.

What do you have to say?

Email (never displayed)
(will show your gravatar)
Please add 7 and 2 and type the answer here: