Work Item: Sprint Backlog Task

Description:

Valid Linkages: Sprint Backlog tasks implement Product Backlog Items. Which in turn are ImplementedBy Sprint Backlog Tasks.

Sprint Backlog Tasks are generated by the team during your Sprint Planning Meeting and are used to record the design breakdown of the Product Backlog Items that have been committed to be completed during the current sprint. In traditional implementations of Scrum, the team also uses the hours remaining on these Sprint Backlog tasks to manage their commitment to the Sprint Goal.

In the same way as Product Backlog Items, Sprint Backlog Tasks are broken down into the Fundamentals, Scheduling and Tracking sections. The workflow is essentially the same, but on a much tighter cadence.

Your tasks should be created, estimated and scheduled during your Sprint planning meeting and then tracked throughout the Sprint.

Use Team Explorer, Excel or the ScrumMaster's Workbench to create your Sprint Tasks - and make sure that the linkages to the PBI are put in place and only valid link types are used.

Fundamentals

Apart from the name of the Sprint Backlog task (which typically describes what needs to be done) - the core fundamentals of a SBT are it's estimated effort (typically in hours) and it's Feature Scope.

If your team doesn't estimate its tasks, but does burn them down, simply set all your tasks all to the same value, for example "1".

Area Path is also included here if your team likes to assign their task via Area Path. Area Path can be used to track technical / functional areas for tasks (in which case your Area path would likely have two distinct trees of areas) - or it can be aligned with the Area Path of the parent PBI, to ensure that the developers don't lose sight of the forest "for the trees" - both uses are valid, and will depend on your project. You may use Area Path on tasks for any purpose you like, (including none) - as unlike the Iteration Path, the format of the Area path are not considered "special" or "reserved" for Scrum for Team System.

Scheduling

As discussed in the Product Backlog Item Guidance, the primary scheduling mechanism is in fact the Planning Scope. The Planning Scope for a Sprint Backlog Task equates to the "Sprint" in which task is going to be completed in. Under normal conditions this should always be the Sprint just commencing.

You will of course need to create the Planning Scope Team Sprint node ahead of when you need it.

The only valid Planning Scope for a Sprint Backlog Task equate to the "Sprint" in which it is going to be worked on.  Since only teams work on Tasks, The Planning Scope for a Sprint Backlog Task should always be leaf node of your Planning Scope, the Team Sprint.

You can also optionally add a priority field to your Sprint Tasks if you have the need to sort your tasks in relation to each other.

Remember that Sprint Backlog Tasks implement Product Backlog Items, so it's generally considered better practice to prioritise these SBT's together as a single list as opposed to an alternate strategy of  prioritising the SBT's as a single list, regardless of which PBI's they implement.

Finally, some tools such as the ScrumMaster's Workbench use the priority field to determine the order in which they display your Sprint Backlog Tasks.

The Task Priority field defaults to a value of 1.

Note on Rescheduling Tasks: Even when using Scrum, things don't always go to plan (in fact, that's one of the primary reasons that Scrum has become so popular, precisely because it allows you to keep your project in control when things aren't going to plan!)

The case in which we're referring to here is more specifically when you plan to complete a Product Backlog Item in a particular Sprint, but for whatever reason you don't.

Scrum for Team System makes rescheduling this work easy. All you need do is change the Planning Scope on the Product Backlog Item, and the event service will change the Planning Scope on all the linked and undone Sprint Backlog Tasks to match the Product Backlog Item - saving you a pile of boring admin, and keeping your Work Items in good order.

You can learn about de-scoping work in more detail in the following blog post:

http://consultingblogs.emc.com/simonbennett/archive/2010/01/22/descoping-work-in-scrum-for-team-system-version-3-0.aspx

Tracking

Once you have created your Sprint Backlog Tasks, you'll want to track their progress. 

In traditional Scrum implementations, teams track their progress towards their Sprint goal by burning down the hours remaining on their Sprint Burndown Chart. 

To support this activity you can track the hours remaining to complete any given SBT, and this will then be reflected in both 

Fields:

Workflow: