Technical Communication teams differ in many ways such as programs for developing content, diverse outputs for documentation, various departments in which they sit, and what I intend to discuss here: different processes for managing work and workload.
You are likely working in a development environment whether you realize it or not. You may work in a Waterfall environment and wait for the trickle feed of information to turn into a massive cascade that nearly knocks you out. Perhaps you fit into a more Kanban approach; you know what tasks are in your backlog and periodically pull from that list as the resources become available. You aren't likely to be in a Scrum environment if your process is not decided. And it is this type of environment that I strongly suggest you consider.
In the book, The Product is Docs: Writing Technical Documentation in a product development group, Christopher Gales and the Splunk Documentation team make a strong case for creating technical documentation in a Scrum environment. So, what more can be said on the topic? Let me start with this—the focus of Mr. Gale’s and the Splunk team’s fantastic book is framed in a way that focuses on teams working within a Scrum environment with Software team members. I propose that Tech Comm teams working on hardware documentation can significantly improve their processes by implementing a Faux Scrum environment for development. A Faux Scrum is also beneficial if your Scrum team doesn’t extend beyond your writers.
A Scrum is a development environment used primarily by software developers and structured with software development in mind. But as I mentioned, Christopher Gales and the Splunk team have already explored how well it works for Technical Communicators. Let me cover some very high-level basics for those new to the concept.
The basis of a Scrum is to break your work into small pieces, each called Stories. Each Story is assigned points. Points are an estimation of the amount of effort the Story will take. Traditionally, this is based on the Fibonacci sequence (1, 2, 3, 5, 8, 13, 40, 100, etc.). While it is easy to tell the difference between 1 and 2 (double the effort), the difference between 99 and 100 is much harder to gauge. Stories make up Epics, which are more significant pieces of work. For example, in our process, the document we are working on is the Epic, and the tasks to complete the document are the Stories. Stories are brought into Sprints during Sprint planning. Sprints are the space for you to complete the stories you commit to during Sprint planning. The duration of your Sprint is up to your team (you can see in our Scrum journey below that we went through a few iterations of our Sprint duration).
The idea is to estimate your Stories; you will be able to specify how much work you can complete in any Sprint. This is called your Velocity. When you hone in on your team’s Velocity, you can adequately plan the appropriate amount of work in your Sprints. You will probably find variation in what a 2 means for each team member because each individual is responsible for assigning points to their tasks. I will say that the whole method takes time and implementation to fine-tune, so don’t feel hesitant if you don't fully grasp what a “2” means to your team at the start.
Like all, my team's Scrum journey was a journey, and the nature of Scrum is ever-evolving to fit the needs of our team. Let me get this out of the way: I am not claiming that we are a true Scrum team, and I understand our concessions. I am hoping that you may be able to take from our learnings in developing a process that works for you. With that said, let me start at the beginning.
I joined a leaderless team as a contributing writer; it wasn’t until later that I became the team manager. We had no actual process of tracking work beyond an outdated Excel spreadsheet hosted locally on one member's computer. I saw a need for organization. I migrated the team from the Excel sheet to a Trello board that I set up. This became my first attempt at organizing our team. It was an easy decision because the program was free and worked with our company’s single sign-on (SSO). So great! We were working in a Kanban environment. And it worked well for a while. But I’ll express my hidden agenda here: I always wanted to move to a Scrum environment. I had previously worked with a software team and was a believer. It wasn’t too long before I found my chance.
My team was moved from R&D to Marketing, so we found ourselves with a new manager. Maybe it is just me, but he asked me for something I dread as a Technical Communicator: KPIs. I had read Tom Johnson’s Technical Communication Metrics: What Should You Track?, so I knew I didn't want to track word count or page count. I took "What you track, you focus on," to heart. I knew these were bad metrics. So, what could we track that would increase our productivity? Sprint story points! Luckily our company also included an SSO for Jira (the program we use today and the program I used in the previous role I alluded to earlier), so again, I had an easy decision. I migrated our workload from Trello to Jira, and we were in a Faux Scrum environment.
I mentioned that our Scrum journey was a journey, so obviously, we didn’t perfect it right away. It took time. I’ll note that it was about this time that I became the manager and leader of our team, so I took the reins on acting in a similar role to the Scrum Master, which we don’t currently have. This means that I owned the boards, I ran our stand-up meetings, and I drove how we were Scrumming. In our first attempt, we ran month-long sprints. Long I know, but we wanted to capture work like "Finalize first draft" or "Complete final draft." We quickly found the danger here. Since we work in a reactionary field, highly dependent on SMEs to deliver inputs like drawings or reviews, some stories wouldn’t be completed for many sprints past the initial plan. Our main KPI was suffering from things outside our control, and beyond this, we weren’t accommodating to new requests. Since we didn’t want to alter our sprint plan, we couldn't take on new work until the next Sprint started, and even then, there was no guarantee that we could even plan it for the next Sprint if we became overloaded with other priorities. Not to mention the difficulty of accurately planning for a month in advance.
So, we shortened our sprints. We went for two weeks. Here we gained agility. We were able to react to new requests more quickly, but we were still planning tasks that were too big for our sprints. After a time, we stopped creating stories like "Finalize first draft" that would carry over many sprints. Instead, we would take our sprint planning sessions as the opportunity to identify the tasks we knew we had the inputs for before we brought them into our sprints, making our sprint planning sessions more active and influential. What was a 4-hour plus session became a two-hour session. This also worked for a while, but there was still room for improvement.
Earlier in the year, we took the plunge and moved to 1-week sprints. When requests come in, we can begin that work as early as the next week, if our bandwidth permits. I must confess something also. We cheat on our story points. Although you are not supposed to link time to your points, we decided that the maximum for our team would be 40 points per person. This equates to roughly 40 hours in our work week. Then when we plan our sprints, we know we cannot exceed 40 points per person. But I maintain that this is what works for our team, and I think that is the spirit of Scrum.
I write this to let you know that if you are like we were, struggling with your development process, you are not alone. Give a Scrum environment a try. As you can see, it’s okay to fail. Just tweak it until it fits your team, and you become even more productive. Don’t feel that because a "true" Scrum doesn't fit your team, you can't Scrum like we do or Scrum in your way.
.svg){kind=small}
.svg)
.svg)
.png)