Using TFS Board to Run a Scrum Sprint: A Practical Guide

In the previous article we introduced the basic usage and features of the TFS 2015 Kanban board; this article demonstrates a concrete scenario—how to use the board to run a Scrum sprint. A sprint is the Scrum iteration unit that contains the core Scrum activities.

Team Introduction

Team composition:

Product Owner: 1

Scrum Master: 1 (team members rotate)

Development team: 8 members (5 developers, 3 testers)

Iteration length: 2 weeks (10 work days)

Average team velocity: 100 (the amount of backlog work completed per iteration)

When forming an agile team, setting a realistic iteration length is crucial; it must balance deliverable size, product‑owner commitment, testing resources, and other factors.

Scrum event schedule:

Iteration Planning: first work‑day morning (Tuesday 9:30)

Daily Stand‑up: every morning 9:45‑10:00

Iteration Review: last work‑day afternoon (Monday)

Iteration Retrospective: after the review on the same Monday

Board layout (image omitted for brevity) uses six columns: New, Current Iteration, Development, Testing, Release (optional), Done. Column states map to New, Approved, Committed, etc.

WIP limits are calculated as follows: the Current Iteration column reflects the average completed backlog per sprint; Development and Testing columns use the formula resource count * 2 - 1 (e.g., 5 developers → 9 WIP).

Two swim‑lanes are defined: Bugs (higher priority) and PBIs. Bugs appear above PBIs to emphasize their priority.

Buffer zones (Doing/Done) are enabled for Development, Testing, and Release columns to make pull‑based workflow explicit.

Starting an Iteration

Before the Iteration Planning meeting, the Product Owner must prepare the backlog, entering items and ordering them by business value and urgency.

Iteration Planning Meeting

The Product Owner drags top‑priority backlog items into the "Current Iteration" column and sets the iteration path.

Development team estimates effort (using a Fibonacci‑like scale: 1, 3, 5, 8, 13, 20, 40, 60, 100) and claims items. Effort (work units) is unit‑less, while hours are recorded on tasks derived from backlog items.

The team defines acceptance criteria together with the Product Owner.

Items are moved into the Current Iteration column until the total work‑units reach the team's capacity, as shown by the Velocity report.

Large backlog items are broken down into tasks to track daily progress.

Daily Stand‑up Meeting

Team members answer three questions in order (developers first, then testers):

What did you do yesterday? (Completed backlog items or tasks; move finished items to the next column.)

What will you do today? (Pull new cards from the upstream column.)

What obstacles are you facing? (Report issues without seeking solutions during the stand‑up.)

If a task is finished, checking its box automatically changes its state to Done, allowing progress tracking at both task and PBI levels.

When a column becomes crowded, the quick‑search feature helps locate specific cards.

Iteration Review & Retrospective

The team delivers completed items from the Testing column to the Product Owner. Accepted items are moved to the Done column; rejected items are tagged for the next sprint and re‑planned.

Other events related to the review and retrospective are omitted for brevity.

Future posts will discuss how to improve source‑code development efficiency on the TFS platform.

Follow the WeChat public account "devopshub" for more DevOps and R&D integration information.