How do you track your documentation work in Jira (hierarchy of work)?

[Michelle Rau HP]

This is maybe more of an Agile or Scrum question, but here goes. As a technical writer, some of my documentation work for a project aligns with specific features for the project, and some of it pertains to the project overall. It has been challenging to track my docs to-dos in terms of Epics, Stories, sub-tasks, etc. (I usually use Jira, this current project is tracking in Azure DevOps but the principles are the same.) 

I typically don't operate at the Portfolio Epic or Initiative level, those items are determined by management.

Some docs work for the entire project could potentially be at the Epic level, since some of it will take multiple sprints for it to be completed, or it pertains to the entire documentation site. (These would be tasks like information architecture, setting up feedback mechanisms or analytics, branding, search config, about this site, etc.)

Some docs work aligns with a specific feature. This could be docs on how to setup a widget, which get developed while the widget setup module is being built. "How to use the deploy module" docs work would align with the development work on the deploy module itself, so that when the module is ready the docs are ready too.

I'm pretty sure I need my very own Epic to capture the work that doesn't pertain to a feature. How do the rest of you do it?

[Ste Wright]

Hi @Michelle Rau HP 

I'm assuming your structure is something like Initiative > Feature > Epic > Story/Task, to allow for me to make suggestions.

The reality is though, that it depends on how the work is structured and tracked at a project/program level.

---

Whilst there's no one answer - I would recommend that technical writing is part of the definition of done (DoD) at the most appropriate levels - i.e..

• The highest level where you can classify all the work for a single item to be done
• Subsequent levels where necessary - given some work might be Feature-level, and other work Initiative-level

Then I would consider...

• Statuses: Ensure at each level there's a Status which (broadly) relates to technical writing. To track completion, each level should be considering all pre- and post-software tasks, including technical writing, change management, etc.
• Project: Consider your Jira Project (or equivalent) structure - eg. are Projects representing teams? If yes, should you have your own Project? Or perhaps be part of a "System Team" Project who work across multiple other teams? This would give you a place to house your day-to-day Tasks.
• Work Breakdown Structure: I think this matters less once you decide on the appropriate tracking level. But I'd consider...
  • If using the hierarchical levels, ensure each can be covered. So if you are tracking work at the Initiative level, you'd need to consider if you can create Features, Epics, and Tasks relevant to technical writing (or a combination of other types of work).
  • If you can't I'd consider if there's a way to keep technical writing at a specific level where you can do this - eg. below Feature.
• Linked vs Hierarchical: The other alternative is consider technical writing as a dependency, but not something which is "part of" the hierarchical structure. You could then use linked issues to relate the work to an Initiative, Feature, etc, and make it so that all dependencies must be completed before work is finished. In this scenario, it's then up to you to decide at what level you create your work structure.

---

^ Let us know if any of these sound like they might work for you!

Ste

[Benjamin GILIS]

Your answer is clear and helped me with a few hints. Thanks