Among the forms of agile development that teams can choose to follow, scrum is one of the most widely adopted. Scrum is an agile development approach that emphasizes close communication through daily stand-up meetings with the goal of increasing speed and flexibility in the development process.
A scrum team consists of the product owner (often the product manager), Development, Quality Engineering, and Information Development (that’s you!). It’s important that writers work on the scrum team alongside Development and QE to stay involved with all facets: design, backlog grooming, development of the product, etc.
When they look at scrum from the outside in, most writers tend to get excited about the possibilities of this development model—and with good reason. The amount of interaction and communication on the team facilitated by daily standup meetings and frequent planning meetings is like music to the technical communicator’s ears. The proper self-management and direction on a scrum team makes all the difference in getting a result of a beautiful, well-harmonized song vs. suffering from the screech of nails grating on a chalkboard.
How are Writers Involved in Scrum?
The advantage of scrum is that writers are an instrumental (ha – get it?) part of creating that beautiful song. If you aren’t involved in the ways you need to be, part of the harmony will be missing. And it’s much more difficult to add those pieces in later.
Let’s start at the beginning of the release cycle with backlog grooming, where being involved in the whole process ensures a higher quality and more complete end product. During backlog grooming, the scrum team discusses requirements and estimates the effort of the whole team to fulfill that requirement through one or more user stories. Think of backlog grooming like composing the song, with each user story being a few measures that connects to the next set of measures in the song’s flow from beginning to end. Including the documentation part in that estimate upfront helps set the proper expectations for the team for that work, and eliminates surprises down the road. In addition, your presence in the discussions where the product owner clarifies requirements for the team helps you write accurate, thoughtful documentation. Frequent grooming sessions ensure that the team continues to hit the right notes throughout the release cycle.
Once a sufficient product backlog has been built up, the scrum team can turn towards release planning, where they choose a set of user stories that match the product owner’s release theme to work toward a timely release. As the information developer, you must be involved in these planning discussions as well so that you know and can contribute to the overall schedule, including planning your documentation, user interface reviews, and usability testing milestone dates accordingly. Involvement at this level helps you keep the same tempo as the rest of the team. All parts of the song should end at the same time.
Sprint planning is probably one of the hardest things to do as a writer on a scrum team. Keeping your tasks in line with the Development and QE tasks in user stories can be an exercise in frustration if your fellow team members don’t plan in a way that allows time for your work in the sprint as well. If your work is not included in the same user stories with Development and QE tasks, you’ll have a song at the end of the sprint, but it will be missing some lovely harmony. Sprint planning activities are your contribution to orchestrating the piece, and working with the other musicians is key to developing the complete score before the performance.
The Benefits of Scrum for Writers
The scrum approach includes writers in all areas of the product development, and that’s crucial to your success on the team. When you are tuned in from the beginning and know the requirements, design, and thought behind the design of the software, not only do you get the essential information you need to write on the product, you demonstrate to the other functional teams (Development, QE, etc.) that you are serious about learning the product. That gains you invaluable respect, some good notices, and an invitation to join the orchestra for the next season.
Agile development relies heavily on frequent and clear communication. The standup meetings, grooming meetings, and planning meetings are all perfect opportunities for writers to gain more product knowledge, further build relationships with their team members, and help solidify the overall team approach. Working with the team sprint after sprint is like practicing an instrument—the more you do it, the better you get.
Participating as an equal member of the scrum team from the beginning of the release cycle also opens up more opportunities to influence product design. You can do this in several ways—offering opinions in backlog grooming and planning meetings, doing UI reviews for the developers, and running usability tests, for example. Any time you make the product design better, the less you have to try to document around it.
Finally, if your team works with customers to show them your sprint demos, you gain valuable feedback from those customers that can help you tweak both the product, and the way you present it in the documentation. Seeing your audience smile and nod along during a beautiful song is always preferable to someone cringing when you hit a wrong note.
Done well, scrum provides tremendous benefits and opportunities to writers who have not previously gotten involved in various areas of project planning and execution. Knowing where and how to contribute helps you gain clout on your project team, increases the quality of the product and documentation, and solidifies the team dynamics. Now go make some beautiful music!
References and Useful Links
- Scrum Overview, Mike Cohn (http://www.mountaingoatsoftware.com/agile/scrum/overview)
- Scrum and the Single Writer, Kathee Kuvinka (http://www.writersua.com/articles/scrum/)
- Introduction to Agile Methodologies, Sarah Maddox (http://ffeathers.wordpress.com/tag/scrum/)
- How Does Agile Affect Documentation?, Mary Connor (http://www.cleverhamster.com/clever_hamster/2011/02/how-does-agile-affect-documentation.html)