Wednesday, June 05, 2013

MSF Agile 6.x Boards and how to do Bug Management

I am using Microsoft Solutions Framework (MSF) for Agile Software Development latest version, i.e. 6.2, although this should be valid for any 6.x version.

In TFS 2012, latest version of both Agile and Scrum templates come with boards for tasks and work items. I am not able to find anything for Agile boards, although there is info available for boards in Scrum Template which are very similar to boards in Agile Template.

Agile boards are for user stories and for tasks within user stories  So one cannot see bugs and their child tasks. Same is the case with issues and their child tasks. One solution to this problem is to make a fake user story per bug. Others have explained how to modify the template so that one can see bugs in the board. MSF folks also seem indifferent to whether TFS users plan bugs with user stories or separately hence they have also written on how to add bugs to the task board or backlog.

I discourage above solution as giving story point to bugs is not a good idea (see last para) and so is cluttering real stories with fake stories especially when bugs count is usually more than stories count. Now here is my take on how to manage bug in MSF Agile 6.x.

  • If a bug is in a user story that one is currently working on in the given iteration, then add both that bug and associated tasks such as "fixing the bug with approach XYZ" as direct child of the user story. I believe time tracking is actually needed to know how much time one needs to spend, or for that matter has spent, on the user story. And this way you have included time spent on fixing bugs injected while working on that story. If one really needs to audit time spent on such bugs, then link appropriate tasks with the bug as "related". 
  • Now if a bug is in a legacy story then that should be fixed outside iteration capacity and thus should not be managed on board. So a team that has lot of legacy bugs can commit spending 30% capacity on fixing legacy bugs i.e. they will plan for stories with 70% capacity. Now as long as these bugs are stack ranked, whenever a developer has time he can pick the top one and fix it. 

Why outside iteration and why no need for story points? Well actually these legacy bugs are slowing ones velocity and to me are more like impediment to the user stories that otherwise team would be working on.  So if there are lots of high priority legacy bugs then a developer or two can commit 100% of their capacity to bug fixing for a few iterations. Bottom line is board are for real stories.

No comments: