Managing Documentation Projects in Team Foundation Server, Part 1: Planning the Sprint

Here is the first of a series of three posts on how we use TFS to managing our internal documentation projects. They are compliments of my friend Allen Clark in our User Education group. He provided all the content for these posts. (Thanks Allen!)

------

The team that writes online Help topics for Team Foundation Server manages its work using a scrum-like process. It’s not the same scrum that you’d see on a software team because we’re grappling with different problems. The principles of scrum, though, give us a framework for managing our immediate work on a day-to-day basis. This series of posts will describe roughly how we do it.

We work in sprints that are usually a month long. Each sprint starts with a planning meeting and ends with retrospective. We start the planning meeting by reviewing important milestones that we need to reach during that sprint. We have to look ahead one or two months to make sure that we don’t get caught in crunch mode. For example, we might be handing off a set of content for localization in about two months. To do that, we have to make sure that it’s all been written, edited, reviewed by the product team, updated based on the reviews, and then proofread. In that case, we’d make it a priority to prepare the content ready for tech review in this sprint. We have to make that goal so that we can finish the work and hand it off to localization on schedule (in a future sprint).

Given that context, each member of the team proposes a set of scenarios to cover. They might be improvements to existing content based on feedback that we receive online, or they might include new content for features that are under development. We prioritize those on a three-point scale, which is defined roughly as follows:

1 – It is important to complete the work this sprint.

2 – We’ll complete the work this sprint if we can get to it.

3 – We probably won’t get to it this sprint.

We review the priority 1 work for each person on the team to see if she is comfortable that it’s a reasonable load and load balance as necessary. Sometimes, we have to re-prioritize to keep the sprint workload at a reasonable size.

During the meeting, we keep notes in a shared OneNote notebook, with the prioritized and assigned scenarios in a table. Anyone at the meeting who has a laptop computer can add items as we work through them. Here are our notes from the planning meeting for September 2007, with some information omitted.

September Sprint Planning

Tuesday, September 04, 2007

9:26 AM

Important Dates

Sept Continuous Publishing

9/17 Sept Continuous Publishing: Writers and Editors Complete

9/19 Sept Continuous Publishing Visual Test Pass

9/21 Sept Continuous Publishing Lockdown

Milestone LH4

9/7  Writers Complete

9/10-11 Index bash

9/14 Editors Complete

9/17-18 Visual Test Pass

9/21 Orcas Content Freeze

Milestone R

9/17-21 Poster week

Suggested Scenarios

After the planning meeting, we break our scenarios down into tasks in Team Foundation Server. In my next post, I’ll talk about how we use work items to manage our work and track our progress over the course of the sprint.

-- Allen Clark (blog)