Sprint but Iterate: How Product Content Pros Can Adopt/Adapt Agility (Part 2)

Sad as it is to say, self-directed, collaborative, and agile product development teams often don’t get content. That is, they don’t really understand where content comes from, how it is best developed, how to work with content creators, what’s required of the team as a whole, and why developing content can sometimes take longer than a 2-week sprint.

So it is often up to content professionals to educate (constantly), adapt (when necessary) and, above all, speak up about their requirements.

In the first blog post in this series, I outlined the inherent tensions in the Agile methodology, especially for content creators, and then described 5 ways in which Agile projects should accommodate contemporary content development needs.

In this blog post, I’ll lean on my own experience.

That experience included my attempts as a content strategist to adapt to the evolving Agile product development environment, which included an ever more complex web of JIRA-based tickets and artifacts.

Context of my Experience

To begin, I should describe the environment in which my most recent content development team endeavored to produce product content for a complex, technical product.

The larger product development team originated as a start-up business, which was acquired by a huge corporation. This circumstance is not unusual. The challenge lay in the disparate feature-focused development teams, whose output was loosely coordinated.

The corporation demanded standardization and attention to deadlines. Enter the brave and Agile project managers.

I observed from afar, at first, how these gallant souls began to steer the ship. Suffice to say that the various product development teams moved away from creating detailed product specification documents to creating team-level initiatives, epics, stories, and tasks in JIRA (an Agile/Scrum management tool from Atlassian).

While the change was gradual enough, no one on the project management team thought to train the content developers on how to engage with this brave new world. We found ourselves adrift – and, admittedly, a bit outraged. So we had to educate ourselves and adapt quickly.

Agile Evolution

As a result of my corporate experience – and in talking with others – I have observed three approaches to Agile “content assignment-making” through JIRA. Each approach represents a type of project management maturity. Each has its benefits and drawbacks.

1 – Content Assignment Tickets from Product Teams

In the first approach, a feature-focused member of the larger product development team creates a JIRA ticket and assigns it to the lone content developer who works on that product specialty. I call this the “throw it over the wall and hope not to think about it” scenario.

In its impact on the content writer, this scenario is not much different from what occurs in the traditional product development model:

• A content writer is assigned to “support” a team, often after product development is well underway.
• Content serves the product but doesn’t necessarily become an integral part of the product – or of the product development process.
• Content requirements are often explicit and focused on a preconceived deliverable – curtailing creativity.
• Content assignments (“tickets”) are feature-based. That is, the assignments assume a one-to-one relationship between a product feature – such as a menu option – and content output.
• Overall, the product team, not the content team, assumes the power to determine whether content is needed.

In my work experience, this scenario occurred before project management was centralized and before the siloed sub-teams were forced to align their efforts. To their credit, the feature-focused sub-teams wrote their content JIRA tickets while the feature was still evolving – usually when it was going through initial testing. So the assigned content writer had some opportunity to influence the final version of the feature.

Another positive for the writer was the level of detailed explanation some of the developers included in the content tickets they wrote. That detail often helped the writer understand both the feature and the product better. However, the provision of this detail was the exception rather than the rule.

That said, this first approach has its workload and workflow drawbacks:  

• Many developers can assign many feature-based tickets to one content writer, resulting in a large number of small, discrete content assignments.
• The designated content writer has to respond to every ticket, which constitutes a lot of busywork.
• Work progress measures can get lost in the shuffle, especially when the writers’ tickets are removed from any team “burn down” (because content is not considered an essential part of the product).
• User research and task analysis, if they exist, are several steps removed from the content development process. Task analysis often has been performed, but only to the extent that a product feature has been identified.
• No centralized content strategy is driving the writer’s assignments.

Finally, this scenario often assumes dual reporting structures for the writers – to the feature-based development team that assigns the work and to a content team manager who evaluates the work. Nightmares are made of such stuff.

2 – Content Corrections through Tickets                                    

In the second approach, only content corrections and improvements to existing content are requested through JIRA tickets. This effort is usually balanced by a separate, centralized content development tracking system.

During my recent corporate experience, I ran a weekly Monday stand-up for content developers that ostensibly focused on JIRA tickets containing content corrections and improvement suggestions. We all enjoyed these meetings for various reasons (think inside jokes), but their primary benefit was to get everyone aligned on who was doing what during the upcoming week to reduce a backlog of JIRA tickets.

Soooooo that meant that we had to talk about the assigned content development work, too. Plus we had to talk about who had other obligations or vacation time that week, and so on. Thus the objective of the meeting often became not how to improve content but how to balance workloads.

This experience highlights one of several challenges that can arise when a work ticketing system, such as JIRA, is used exclusively to assign content corrections and improvements. Here are some other challenges I have experienced or learned about from others:

• This approach is not really Agile development; it’s corrections tracking with some applied agility.
• To work well, this approach requires that all content pieces (website topics, help topics, videos, guides, and so on) have specified owners; otherwise, your stand-up becomes a game of “hot potato.” (Kindness and a willingness to help mitigates this game.)
• If the requested corrections are too granular (for example, “add a comma”), the overhead of busy work leads to diminishing returns.
  • Note:  A good editing process that looks at the entirety of a piece of content or set of topics is a better option than assigning style edits through JIRA.
• When content team members write tickets against each other’s work, the discussion can devolve into sniping or tit-for-tat ticket assignments. (Humor helps to mitigate this.)
• When the request for correction is unclear or has larger implications, engaging the ticket-writer exclusively through JIRA can be counter-productive and add to busy work.

The last point speaks to the situation wherein a website visitor, internal or external, requests a correction or improvement to a piece of content. If the requestor is external to the organization, the request is often unassigned (except to the team at large). The content development team, then, has the opportunity to discuss the following during a weekly stand-up or similar meeting:

• Who should take on the work?
• How does the work relate to other work?
• How should the work be prioritized?
• Who should respond to the requestor? Through what channel?

If the requestor is internal – say, a customer service representative – they will often assign the ticket to a content developer they know. Sometimes the requestor hits the mark, and sometimes they don’t. If the requestor includes a due date in the ticket, the receiving content developer feels pressured to do something inside of the JIRA system – either reassign the ticket (think “hot potato” again), prioritize the ticket request over other work, or engage the requestor with a series of ticket-centric questions. Depending on how JIRA is implemented locally, a content developer might also opt to mark the ticket in such a way as to defer or decline the request.

Often, none of these options fully satisfies. So I suggest that if your organization allows internal content users to create JIRA tickets for content corrections, you, as a content leader, should insist on the following:

• The tickets are initially assigned to a content team moderator, who is empowered to reassign them or decline them.
• The content team meets regularly in a session that is dedicated exclusively to discuss open tickets.
• That meeting should include a discussion of the “who” and “how” questions that I list above.
• The team prioritizes human engagement over JIRA engagement.

In other words, as much as possible, treat internal tickets like external tickets.

All of this still leaves a content developer assigned a content correction ticket with the potential of work assignments coming at them from multiple directions. Sharing ideas during a meeting helps. To assist with the workload, my content development team also instituted three rules:

1. Minor changes (remember, that comma!) should be handled outside of the JIRA system – through email or <gasp!> in a face-to-face conversation. The content owner, then, has the option to write a JIRA ticket and assign it to themselves (for example, for tracking purposes).
2. As much as possible, multiple changes should be combined in one JIRA ticket:
   • For a global change, write a single JIRA story and allow content developers to assign themselves task tickets as part of this story.
   • For multiple, discrete changes to the same piece of content, create a single JIRA ticket. This practice enables the content developer to make a single pass through the targeted content piece.
3. If a requested content correction is unclear or complex in nature, the assigned content developer should clarify it with the requestor outside of the JIRA system. (They can always summarize the discussion later inside of the ticket itself.) Decisions about the next steps should stem from that discussion.

The overall challenge with this second approach is that separation between correction and development assumed at the beginning. What happens if a request for content improvement really represents a request for product improvement? A feedback loop should exist between the content correction effort and the content development effort and ultimately should encompass the product development effort.

Additionally, a content corrections ticketing system should not replace a content assessment or continuous improvement effort. As I noted above, a good editing process should forestall a tendency to “edit by ticket” another’s content. More importantly, improvements to content standards, content tools, and content operations deserve their own space, perhaps even their own JIRA epics. The key is helping the content developers manage their workloads when they are assigned work from multiple sources.

 3 – Content Strategy within Tickets

The third approach that I’ve seen because I tried to architect it myself, leverages JIRA to assign content development work. Initially, the content developers were assigned work outside of the JIRA system. But eventually, we used JIRA both to describe a content strategy for a set of user tasks and to assign the content development work to manifest the strategy.

The evolution of this approach arose from two places:  accumulated experience and necessity.

In my corporate experience, when the product development team abandoned full-blown spec writing, the content developers, who were not yet fully trained on Agile processes, felt disconnected from the big-picture product goals. Soon, the sheer number of JIRA tickets generated by the “team of teams” Agile development process overwhelmed any one content developer’s ability to interpret the product development work into content development tasks.

So as content strategist for the team, I assumed the role of interpreter. In that role, I would research new and evolving features, as the need arose, and then provide an overview of the impact on our audience and existing content. For the overview, I developed a table on a wiki page (using Confluence). I organized the table rows by product feature because that was how the product development team discussed its work.

In the table row for the change, I also included the following:

• Definition of the feature, if the terminology was new
• Short, high-level explanation of the change or difference
• Short description of the impact on the user
• Short description of the impact on existing content
• Names of SMEs
• List of related JIRA tickets and engineering documents (with links)

This approach worked well for well-defined changes and minor new features in an existing product. The content developers appreciated that they could go to a single source to understand the new product version and its impact. We still tracked content development work in a separate system. But in the end, the team successfully launched new and revised content to support the new product version.

Then things got complicated. The next version of the product involved more than a couple of new features and minor changes. It involved a complete overhaul of the product. At the same time, management mandated that all content development assignments must be done through JIRA.

In response, I organized some brief training for the content developers on JIRA basics, and we ventured farther into Atlassian land. Luckily for me, I had some time to organize this approach because the content developers were still working on an all-hands-on-deck assignment to develop system messaging content.

Leveraging my previous “interpreter” experience, I developed a content strategy in JIRA that followed these principles:

• All content strategy for a product feature is contained in a single JIRA epic.
• The epic begins with a brief explanation of the feature and its implications for product users and content developers.
  • Note that if a new feature has no impact on the product user, no content strategy epic is created.
• The epic outlines the new user tasks implicit in the feature, as well as any supporting concepts and reference material that might be needed.
• The epic suggests but does not mandate a set of content deliverables (video, man page, web page, and so on) for the feature.
• Attached to each epic is a combined content audit and plan for making changes to existing content. (I used a spreadsheet format for this document.) (For more on combining content auditing and planning, read my previous blog post “How to Develop a Combined Content Audit and Plan.” )
• Linked to each epic are the related JIRA tickets from the product development team.
• Management or the content developers themselves can derive or associate JIRA stories and JIRA tasks from the content strategy epic – for tracking the actual development work.

Below is a partial example of a content strategy epic that I wrote in JIRA.

The ticket goes on to include requirements for task topics, reference topics, troubleshooting topics, and glossary topics as well as ideas for videos.

This JIRA-centric approach has the following advantages:

• The content development team has the power to determine what content gets developed for the new product version.
• Content developers can go to a single source (the content strategy epic) within a centralized system to understand the implications of a new product feature.
• Content developers can follow direct links to the product team’s JIRA tickets, where they can uncover additional feature details.
• The product team can “see” the content team’s progress on the content work, by virtue of the fact that all work was now tracked in a single, central ticketing system.
• The content developers are free – although some might argue otherwise – to scope and assign their own work within the larger content strategy (epic).
• All tickets flow from a centralized content strategy, always.

The challenge with this approach is that content strategy and development are still separate from product development. In my corporate example, the content team’s tickets could only be associated, not derived from the product team’s tickets – lest the content team mess up a scheduled Agile “burn down” by the product team. Additionally, the product team’s tickets were often completed long before the content team’s tickets were, so the content team had little influence over feature development.

The JIRA-centric approach also came with some content operations challenges in my corporate situation. We didn’t hold weekly stand-ups because the content developers were all working on various features at the same time. Because we didn’t hold those standups, the content developers sometimes became confused about priorities in their workloads, which only added to their feeling of disconnectedness.

Additionally, the application of content standards, including CMS-related tagging standards, and content review processes began to fall by the wayside. An overhaul of processes was long overdue. But we found no easy way to enforce them within the JIRA system. The status updates and reassignment processes available in JIRA didn’t quite meet the need.

Finally, the “busywork” aspect of JIRA ticketing continued unabated – something we never quite resolved.

Conclusion

Its “busywork” nature aside, JIRA continues to hold sway within the world of Agile product development as a way to both assign and track discrete elements of work. In that way, JIRA is not incompatible with content development work. But JIRA – and the Agile development system it represents – has a long way to go to engender agility in content strategy and development. Some elements of centralized processes and standards need to live alongside the integration of content development and product development.

In the next installment of this series, I evaluate “ideal” ways in which content strategy and development can have agility. You might also want to review the first post in this series to determine whether my suggested ideal meets the criteria I outlined there.