Ideally, the way Scrum works is that everyone on a team is a 100% dedicated resource. While developers and QA analysts might have some other small tasks to do while working in Scrum, their primary focus is the team. However, a technical writer might be split between two or more teams, sometimes as many as four or five. When that happens, keep the following in mind.
That’s quite a list, but it’s manageable, and a lot of these only happen bi-weekly, so it’s a little hiccup in the work schedule and then back to it. . . until you double it, or triple it, or more. At that point you will spend all of your time in meetings and none of your time actually writing anything. If you’re going to have any time to work, you may have to skip some meetings. But which ones?
Story pointing meetings are a must. Of all the meetings, this is close to the top of importance. Remember, Scrum uses no specs. Since everyone (except you) is only working on this team’s work and in constant contact with one another, there is little written material for these features. That’s what you’re there for. So, the best way to get a handle on what the features are and what they do is in the story-pointing meetings.
The other essential component as far as meetings go, is the standup. I’ll admit that I work through most of mine; when developers start talking about the particulars of code they’re not having a discussion I need to be a part of. However, by being present at the standups you establish yourself as a member of the team. This is vital for building your relationship with everyone else and putting the idea in everyone’s mind that yes, there is a writer here, and yes, we need to tell him when we change something. And things will change; that’s why it’s called agile.
As for the rest of the meetings, it’s always better to go if you can, but you’ve got documentation to produce, and that takes time too. You have a responsibility to your teams to complete the doc tasks for each story. Sometimes that means you can’t attend every meeting. This is part of the discussion to have with your Scrum master when you explain you’re not an exclusive asset.
3. Focus and Float
Did you know that every time you receive an email it costs you 3 seconds? That’s assuming you don’t open and read it. From the time you see the notification that you have new mail, it takes 3 seconds to reorient your brain back to the task at hand.
The moral of this story is that to be truly effective, you need to focus and shut other things out. No, I’m not telling you to kill your IM channel and close Outlook. But I am suggesting to you that doing one story for one team and then one story for another is slower than taking a chunk of related stories for one team and working on only them for the day, or even the week, and leaving the other teams’ tasks for another time.
Yes, this means that you’ll be going to most your standups and saying: “I have nothing to report today.” That’s fine. Do that.
Understand this might also mean that a sprint may close without your doc tasks complete. How the team handles this logistically depends on the Scrum master. Most of the ones I’ve worked with will pull those stories into the next sprint with a “doc only” tag on it, meaning everything else is done.
Scrum purists might be gnashing their teeth at this, but if you’re willing to give it this little bit of flexibility and break from the ideal of the process (because really, if this were implemented ideally, you wouldn’t be on more than one team), I can promise you this works. While all of my teams regularly carry doc only stories from sprint to sprint, I also always finish ahead of development before the final sprint.
4. Educate Your Scrum Master
When I first started writing for Scrum teams, the Scrum masters would create the same array for each story: a programming task, a QA task, and a doc task. However, not all stories require a doc task. Speak up in the sprint planning meetings and let everyone know what does and doesn’t have to receive documentation so that your workload is accurately reflected in your team’s tracking tool. If you have to miss a sprint planning meeting and you find a story with a doc task that isn’t needed, bring it up with your Scrum master and explain why. Eventually they’ll learn, or at least default to the behavior of asking you first.
Serving on multiple Scrum teams takes some juggling, but it’s certainly manageable. In fact, I’ve come to prefer serving on two at the same time. However, when doing this it’s important to understand that you’re not in the same position as the rest of your teammates, and so you need a different set of rules to be effective.