If you're familiar with Work breakdown structures, you will get used to working with the WBS Editor fast, otherwise it might be a good idea to head over to Wikipedia and read up on them a little bit: http://en.wikipedia.org/wiki/Work_Breakdown_Structure.

The main idea of having a WBS for a project is the following:
  • Structure the work to be done: The tree structure helps in this, and also that you're able to re-structure your work easily
  • Remember the 100% rule: Everything you need to do in order to finish a project should map to some task/work item in the WBS. This is especially important for us nerds and geeks: This implies that you not only model source code changes/tasks, but also testing, release management etc. It takes time, thus has to appear in the tree.

Those are actually the main two reasons to use a WBS at all, and the WBS Editor adds a couple of extra goodies to this:
  • Create tasks directly in the WBS Editor and do a rough estimation, then assign the tasks to (real) persons
    • Do a resource workload review to check that your needs are met
  • Track the progress of the project by connecting the WBS to actual tasks in Team System

If you're not only tracking a single project, the real use of the WBS Editor starts to emerge:
  • For all WBS projects across an iteration, create a workload analysis of remaining work
  • Create personalizes WBS for a single person which shows in detail in which projects he or she is involved in


Continue reading here: Step-by-step Project Setup.

Last edited Jun 28, 2010 at 6:57 PM by martindanielsson, version 1

Comments

No comments yet.