Sprint planning meeting using TFS

One of our most important lessons during this first year of development is that there can only be one sprint backlog. As soon as one or many team members starts using their own tools, the sprint backlog becomes useless. For example if there is a sprint backlog in Excel and that is on someone's computer, the others start using their own lists and post-its.
The best part about using TFS for the sprint backlog is that this is the everyday tool of the developers. The possibilities of linking the check ins to actual sprint items makes it awesome. I saw that Rosario will fix the visualization problems we have with getting an overview of related work items (no, links tab and reports are not good and since the excel integration only lets you see that there are linked work items, that is simply not good enough).

During the sprint planning meetings we go through the highest prioritized items on the product backlog. The product backlog consists of scenarios and bugs, where scenarios are our user stories and the bugs are problems that are hindering us from setting the scenario as for filled. Bugs that are related to scenarios are of course linked to these but we also give them the same Importance (or priority if you prefer that term). Please observe my definition of bug in this perspective: it is a problem which hinders us from demonstrating a use case.

We've sorted the product backlog after Importance and Work item type so when we come to a new priority (for example three), we can first see the scenario in the list and after that comes all the related bugs. If there are no bugs related to the scenario, the product owner can decide to set the scenario as accomplished. I like doing that during the sprint planning meeting so all can see that one of the objectives are reached.

As I mentioned, we go through the product backlog, top down, and the method we use is that we right click the first bug and create a work item of the type task. The task is placed on the sprint backlog by us setting the sprint (or iteration path) to the sprint in question. The task is estimated and then we move on to the next one until the team think they have a good list to work with.