Team Services | TFS 2017 | TFS 2015 | TFS 2013
With Scrum, teams plan and track work at regular time intervals, referred to as a sprint cadence. You define sprints to correspond to the cadence your team uses.
Many teams choose a two or three week cadence. However, you can specify shorter or longer sprint cycles.
Your sprint backlog and task board are designed to support your Scrum processes. In addition, you have access to product and portfolio backlogs and Kanban boards. For an overview of the features supported on each backlog and board, see Backlogs, boards, and plans.
Scheduling sprints involves defining the sprints for a team project, and then selecting the sprints for your team's use. Each sprint that you select for your team provides access to a sprint backlog, task board, and other Agile tools for planning and tracking work.
The images you see from your web portal may differ from the images you see in this topic. These differences result from updates made to Team Services or your on-premises TFS, options that you or your admin have enabled, and which process was chosen when creating your team project—Agile, Scrum, or CMMI. However, the basic functionality available to you remains the same unless explicitly mentioned. For an overview of changes in the navigation experience and working within the user and administration contexts, see Work in the web portal.
For example, by selecting Sprints 1 thru 6, the Fabrikam Fiber team gets access to six sprint backlogs. They also get access to capacity planning tools and a task board for each sprint.
For example, by selecting Sprints 1 thru 4, the Fabrikam Fiber team gets access to four sprint backlogs. They also get access to capacity planning tools and a task board for each sprint.
Terminology note: Your set of Agile tools uses the Iteration Path field to track sprints and releases. When you define sprints, you define the pick list of values available for the Iteration Path field. You use iterations to group work into sprints, milestones, or releases in which they'll be worked on or shipped.
Define and schedule sprints
Your team project comes with several sprints predefined. However, they aren't associated with any dates. For Scrum and sprint planning, you'll want to assign start and end dates for the sprints your team will use.
Defining sprints is a two-step process. You first define the sprints for your team project, and then you select the sprints that each team will use. In this way, the system supports teams that work on different sprint cadences.
Sprints are a shared resource
Because the sprints or iterations you defined are a shared resource, they're managed by project admins. Renaming, deleting, modifying the sprint hierarchy, or changing scheduled dates for an iteration impacts all teams that use it. Because of this, you'll want to coordinate changes when working in an enterprise environment with multiple teams.
Schedule sprints for a team project
To schedule sprints for the team project, you must belong to the Project Administrators group or have your Edit project-level information permission set to Allow. See Customize areas and iterations, Add an iteration and set iteration dates to perform these tasks:
- Define sprints or iterations for the team project
- Set iteration dates
- Modify the name of an iteration
- Change the structure of iterations you've defined
- Archive a set of sprints within a new area
- Delete iterations you no longer want to use
Deleting an iteration will delete all sprint backlogs, task boards, and burndown charts associated with that iteration.
Select sprints for a team
To select sprints and set defaults for a team, you must be a team administrator, belong to the Project Administrators group, or have your Edit project-level information permission set to Allow. See Set team defaults, Select team sprints and default iteration path to perform these tasks:
- To select sprints for your team
- To set the backlog iteration for your team
- To set the default iteration to use when adding new work items within your team context
- To remove selected sprints from appearing on your backlog page
Here we show three sets of cadences defined for the same team project.
|Monthly sprints||2-week sprints||3-week sprints|
Past and future sprints
Your Scrum Agile tools support you in planning and tracking sprints. But they also provide a historical record your team can use to evaluate their progress sprint over sprint. You can access any sprint backlog, task board, and burndown chart from the Past folder as long as that sprint remains active for your team.
Sprints and releases
How do you plan and track a release, in addition to planning and tracking sprints?
One way you can accomplish this is to schedule a set of releases at regular intervals. Then, define the sprints that occur within those intervals as their children. Here's an example of such a structure.
For a worked example of how a management team can focus on releases and feature teams on sprints, see Portfolio management. For additional examples illustrating a release train, see Implement Scaled Agile Framework® to support epics, release trains, and multiple backlogs.
Sprint planning tools
Once you've defined and selected the sprints for your team, you can start using these tools to plan your sprint.
Track team capacity
At the start of each sprint, you'll want to plan the work that your team can commit to. The three Agile tools that support this work include the sprint backlog, capacity planning, and capacity bars. The sprint backlog contains a filtered subset of backlog items whose iteration path corresponds to the current sprint.
Team capacity planning tool
By setting team capacity, the team knows exactly the total number of work hours or days the team has for each sprint. With this tool, you set individual team member capacity as well as days off. And, conveniently, you can set holidays or shared days off taken by the entire team.
Setting capacity for each team member working during a sprint causes the capacity bar for that individual to appear.
You set recurring days off, such as weekends, through team settings.
Individual and team capacity bars
With capacity bars, you can quickly see who is over, at, or under capacity. Capacity bars update with each of these activities:
Here's how to interpret the capacity colors:
Update tasks, monitor burndown
During a sprint, your team can use the task board and sprint burndown chart to track their progress. Your sprint burndown chart provides you with an at-a-glance visual to determine if your team is on track to meet their sprint plan.
Your task board provides an interactive progress board for work required to complete the sprint backlog. During your sprint you'll want to update the status of tasks and the remaining work for each task.
Updating tasks daily or several times a week yields a smoother burndown chart.
Sprint burndown chart
You use the sprint burndown chart to mitigate risk and check for scope creep throughout your sprint cycle. The burndown chart reflects the progress made by your team in completing all the work they estimated during their sprint planning meeting.
The ideal trend line always indicates a smooth and steady burndown. The blue area, however, represents what's actually going on. It shows the buildup of work as team members add tasks and the reduction of work as team members complete those tasks.
Velocity and forecast
While you use sprint planning and tracking tools for each sprint, you use the velocity and forecast tools to estimate work that can be completed in future sprints.
Velocity provides a useful metric for gaining insight into how much work your team can complete during a sprint cycle. And, the forecast tool provides a means for determining how much work your team can complete within a sprint based on a specified team velocity.
After your team has worked several sprints, they can use the velocity and forecast tools to estimate work that can be accomplished in future sprints.
Each team is associated with one and only one velocity chart. The green bar within the chart indicates the total estimated effort (story points or size) of backlog items (user stories or requirements) completed within the sprint. (Blue corresponds to the estimated effort of items not yet completed.)
Velocity will vary depending on team capacity, sprint over sprint. However, over time, the velocity should indicate a reliable average that can be used to forecast the full backlog.
By minimizing the variability of backlog item size─effort or story points─you gain more reliable velocity metrics.
You can use the forecast tool to get an idea of how many and which items you can complete within a sprint.
By plugging in a velocity, you can see which items are within scope for the set of sprints the team has selected. As shown here, a velocity of 15 indicates that it will take three sprints to complete the work shown.
If you work with several teams, and each team wants their own backlog view, you can create additional teams. Each team then gets access to their own set of Agile tools. Each Agile tool filters work items to only include those assigned values under the team's default area path and iteration path.