Scrum: An Agile Approach to Managing Documentation Projects
Do you or your documentation teams face any of these common challenges?
- The product teams you support are developing more rapidly and changing the product design more frequently?
- New work requests come into your team all the time, but you lack a good way to prioritize them against all the other work your team has?
- Writers complain about too many distractions from writing time?
- The product teams you support need more visibility into your team’s work plans and status?
- Your team has more work to do than time to complete it?
- You need to understand writer and editor productivity, resource constraints, and team capacity so you can accurately scope work?
- Your team members need increased skill in accurately estimating hours for required work, even when product features keep changing?
We faced all of these challenges—still do, in fact—and found that Scrum was well-suited to address them. Scrum is a framework for managing complex, changing projects. We each started using Scrum for different reasons and in different ways. This article captures some of the experiences and lessons learned.
A Quick Overview of Scrum
You can find out a lot more about Scrum now than you could a few years ago when we started—some of our favorite resources are listed at the end of this article. But here are the main points:
- Scrum is designed to help product teams complete a shippable unit of work in a short period of time (called a sprint, usually a month long). Work is collected in a list called a backlog.
- Teams are self-managing. Two special roles, the Product Owner and the Scrum Master, help teams move forward.
- Teams plan their work for a sprint in a sprint planning meeting.
- Teams use a daily Scrum meeting to report progress to each other, resolve roadblocks, and make sure everyone is on track.
- Teams hold a sprint retrospective meeting to review what they have accomplished at the end of each sprint.
These are all common elements of Scrum (Figure 1). Rather than give you definitions you can find elsewhere, here is some information about how we use these elements.
Figure 1: Elements of Scrum
Our teams think of the product backlog as a “holding area.” When a Scrum team hears about a feature change or new work, they add a work item to the product backlog. During the monthly sprint planning meeting, they review the work items on the backlog to figure out which ones map to the goals they have set for the sprint. For the work items that map, they figure out the priority and about how long the work will take. Then they add the highest priority work items to the sprint backlog.
If that was confusing, consider the special significance of the sprint backlog. The sprint backlog is the work plan for the current sprint. The Scrum team works from the sprint backlog and tracks their progress against it. The team can add any new tasks that weren’t in the original planning but need to be completed during that sprint to the sprint backlog and then move lower priority tasks from the sprint backlog back to the product backlog so the total work for the month remains achievable.
The Product Owner represents the needs of the product team to the Scrum team. We usually ask documentation managers to be the product owners. Because they have the most contact with the product team management, so they are likely to have the best idea of the big picture. Understanding the big picture is important for writing scenario-based documentation that describes what customers are trying to do, as opposed to what the software does.
Scrum Masters are responsible for making the Scrum process work. They run the Scrum meetings, update the sprint backlog, and run the sprint planning and retrospective meetings. We’ve found that any team member can be an effective Scrum Master, with the possible exception of the documentation manager. Because Scrum teams are supposed to be self-managing, it can be difficult for a manager to step back and allow that to happen. Besides, if the documentation manager is the Product Owner, it’s too much to take on the Scrum Master responsibilities as well. What’s most important is that the Scrum Master be a skilled facilitator who can work well with diverse personalities. A good foundation in Scrum is also helpful, but we haven’t found it necessary to use an officially certified Scrum Master.
Sprint Planning Meetings
Scrum teams use this meeting to plan the work for the upcoming sprint. Writers come prepared with the work they plan to do. The team sets sprint goals and figures out how much time each team member has available. Writers discuss the tasks they want to complete during the sprint, including priority, dependencies, and the estimated time required to finish each task. It’s a good idea to break larger tasks down so that each one takes between 4 and 16 hours to finish.
When prioritizing tasks, we ask our teams to evaluate how well a task maps to the sprint goals, how important the task is for customers, and most importantly, how stable is the product area the task describes? In Scrum, there isn’t time for writers to be wrestling with a product that just isn’t stable enough to install and work with. It is better to defer the work until the next sprint.
We ask our Scrum teams to set goals for each sprint. These might be customer-centric goals, such as deciding to focus on the backup and restore story, or they might be content stabilization goals, such as buddy testing all the procedures in the documentation set. These goals help keep the team focused, which is important in our situation where our documentation milestones are usually much longer than a sprint. They also help us show steady progress to our product teams in a way that is more meaningful than simply reporting how many tasks we completed during the sprint.
Our teams can choose additional criteria that tasks must meet before even being considered for a sprint; for example, teams might decide that nothing goes onto the sprint backlog until a signed-off spec exists or that a particular sprint will focus only on writing tutorials.
Daily Scrum Meetings
Scrum teams use this 15-minute meeting to report their progress to each other in terms of what they did yesterday, what they plan to do today, and what blocking issues they have. Sometimes it is most efficient to resolve a blocking issue in the meeting; other times it is most efficient to “take it offline,” scheduling a separate meeting to resolve it. A good Scrum Master can effectively choose which technique to use for each issue.
Some team members complain about the daily meeting. Sometimes the complainers are people who benefit the most from public review of their work, but admittedly it is difficult to find a time that works for everyone. Keeping the meeting as short as possible is important. We resolved a problem with excess socializing during the meeting by having people who wanted to socialize gather 10 minutes early. A team spread across three different time zones used a network share to post electronic documents of their progress instead of trying to meet every day. A team of just two people realized that meeting every day was overkill; they met once a week instead and were more productive.
Sprint Retrospective Meetings
Scrum teams use this monthly meeting for two purposes. Team members present what they accomplished during the sprint to the product owner. They also hold a post-mortem of the sprint they just completed, discussing what went well, what didn’t, and what created roadblocks. They create an action plan to address the roadblocks, review what work didn’t get done, and make any necessary tweaks to the process itself.
Presenting what was accomplished during a sprint can be tricky. It is not a good use of people’s time to watch the product owner read completed content. Our teams have sometimes dispensed with the retrospective, moving directly to the post-mortem. Some team members bring print-outs of their work for the product owner to read later, using the meeting time only to highlight particular problems solved or work they are proud of.
Results of Implementing Scrum in Our Projects
Our teams implemented Scrum in different ways, but we found some common benefits as a result of adopting it.
- Increased leverage on product teams for stable specs. We used Scrum to apply pressure to development to stabilize specs before sprint planning. If the specs weren’t stable, we wouldn’t work on that feature until the next sprint. Sprint planning also helps the writers predict how much time they need from development each month (tech reviews, spec walkthroughs, etc.), which allows the developers to plan time for that work and results in better responsiveness.
- Reduced randomization. When a development team delivers a new feature spec in the middle of a sprint, the writers are not interrupted. They add the new work to the product backlog and evaluate it during the planning meeting for the next sprint.
- Better planning of writer time. Writers could account for vacations and down time. They only planned work that they could accomplish during their time available for each sprint. Managers could more easily see what writers were being asked to spend time on and how many “ad hoc” work requests came up.
- Increased visibility for product teams. The product teams can easily see what documentation work is being done on a daily basis; they know where they are on the product backlog and how much writing time they will get from each sprint. They can also view the documentation work’s progress throughout the sprint and quickly see whether the work they need is on track.
- Less “throw-away” work. For example, a feature’s draft spec called for documenting 33 types of events. However, the spec wasn’t signed off by the time we started work on our sprint backlog list for that month, so we excluded it from the sprint and postponed work on that feature’s documentation until the spec was signed off. At the beginning of the next month, the writer went back to the PM to get the current spec and see if it had been signed off on yet. It had, but in the final spec, only 11 events were included with the feature. If we had started documenting the feature from the draft spec (as we had done before we began using Scrum), we would have wasted the work of writing at least 22 topics.
- Improved productivity. Scrum applies a little pressure to the writers every day. Their planned work, actual work, and overall progress is visible to their teammates, manager, and product teams, which provides a more concrete sense of accomplishment. Writers tackle one task at a time; they don’t jump from project to project as much and are able to remain more focused. Using Scrum, teams become more self-managing, and communication within the team improves.
Scrum is ideally suited to address the challenges facing many documentation teams today. Sprints break work down into manageable chunks. Backlogs keep track of all known work and provide a place to enter work requests that come up during a sprint. Writers handle work on a first-in—first-out basis, but they can make adjustments to their sprint backlog during the sprint if necessary. If a product team requires new work during a sprint, the writer can add it to the sprint backlog and move an equivalent amount of work off the list. The result is that we track all necessary work, the team finishes the highest priority work first, and the writers no longer feel pressured to simply absorb additional work.
Julie MacAller manages the documentation teams for Visual Studio Team System at Microsoft. Her teams have used Scrum to manage the content deliverables of a new and expanding product since 2004 and are now adapting it to a continuous publishing environment. Julie has been at Microsoft for 12 years and in the technical communications field for more than 20. She has a BA in English from California State University, Northridge.
Ann Beebe manages the documentation teams for Visual Studio at Microsoft. Her teams have applied agile project management approaches to content for the past three years. Ann has been a User Education Manager at Microsoft for 11 years. Prior to joining Microsoft, she managed documentation teams for Barfield, Cauthen and Associates in Atlanta, and for Sales Technologies, a division of Dunn & Bradstreet. Ann has a BA in Journalism from the University of Central Florida and pursued an MS in Technical and Professional Communication from Southern Polytechnic State University in Marietta, GA.
Agile Project Management with Scrum
2004, Redmond, WA
Ken Schwaber and Mike Beedle
Agile Software Development with Scrum
2002, Upper Saddle River, NJ