29 Dec Article of the Month
JIRA — An effective way to track your tasks
— Akash Jujam
Technical writers often struggle with JIRA, whether it is about completing tasks within a sprint, estimating tasks, overcommitting to tasks, or having a bird’s eye view of the progress. JIRA is misunderstood as an overhead of maintaining and timely updating our progress.
On the contrary, JIRA is the most effective way of managing our everyday tasks. The task can be as small as updating one line in a document or creating a new topic. It can also help in managing tasks like rebranding and publishing documents or converting documents from one source (Flare) to another (DITA).
Let’s break the stereotype that JIRA is meant only for developers.
As technical writers, we juggle between various products and their documentation. This means that we support different product teams and attend different scrums/stand-ups. The major challenge is tracking our work across different JIRA projects. Moreover, each product team may follow a different process. This article covers certain aspects of the tool that I personally found very effective.
Create a personalized JIRA filter
The best thing about JIRA is its capability to filter and show customized information. Though default filters are available, I would recommend creating your own, based on the fields that are most important to you; some fields may vary depending on your organization’s JIRA settings.
For example, you can use the following fields to create a filter:
- Product Edition
- Fix Version/s
- Labels
- Component/s
A filter with a specific Product Edition and Fix Version/s can generate a list of issues targeted for a particular product and release.
Create JIRA epics for feature documentation
Some teams follow a process of creating documentation tasks as JIRA subtasks under a developer’s user story. However, this process may act as a blocker for developers as they are unable to close the user stories without the respective subtasks being closed. It is also difficult to accommodate the tasks for multiple drafts and reviews under a Dev user story. This problem can be solved by creating a separate epic for documentation. The documentation epic can be linked to the engineering/development epic to maintain relationships between tasks. A documentation epic can hold tasks, such as:
- Feature documentation draft 1
- Technical review draft 1
- Feature documentation draft 2
- Technical review draft 2
- Feature documentation draft 3
- Technical review draft 3
- Publish final document
This way, documentation tasks can be tracked at a granular level and provides a better visibility on the status. As review tasks can be assigned to the respective stakeholders, it helps track the reviewers’ effort as well.
Create review tasks
Mostly, a documentation task is a stand-alone issue that is assigned to a writer. Therefore, this singular JIRA issue is also used for non-writing tasks, such as technical reviews. A few drawbacks of this method are:
- The same documentation task reassigned to a stakeholder for a technical review does not give clarity on the status.
- Accountability is lacking as the task is reassigned back and forth.
- It is challenging to maintain the review history.
- The estimate cannot be exact as the technical review is an external factor that affects the timeline directly.
Creating a separate review task can help avoid all these challenges and build a sustainable process to make sure that technical reviews are done on time.
Estimate your tasks
Estimation is very crucial in effectively managing tasks as it allocates a practical timeline to the assigned tasks. It’s usual to receive tasks with a deadline but it’s our job to analyze whether it fits within the schedule. We often estimate only the number of hours required to complete a task, but JIRA has the concept of story points. It denotes the complexity of the task and the efforts needed to complete the task. While the calculation of story points may vary across organizations, here’s an approximate mapping of hours with story points.
| Range of hours | Difference | Story Points |
|---|---|---|
|
1 to 16 |
15 |
1 SP |
|
17 to 32 |
15 |
2 SP |
|
33 to 60 |
27 |
3 SP |
|
61 to 100 |
39 |
5 SP |
|
101 to 150
|
49 |
8 SP |
|
151 to 240
|
89 |
13 SP |
You can create your own mechanism to calculate story points. However, the best practice is to keep a total of 15–18 story points for one sprint. The number can be higher if there are smaller tasks with one story point. The idea is to understand how much you can deliver each sprint. Your estimation will improve with practice. It helps you prioritize tasks based on your bandwidth (or available story points) and take up tasks that can be delivered within realistic timelines.
Create a separate JIRA project
When you work on multiple products, each product may be associated with its own JIRA project. This forces us to work on multiple projects and does not provide a single view of the tasks at hand. JIRA filters can help, but with certain limitations as each product’s JIRA project may have a unique set of fields.
Managers can work with the Program Manager or IT Administrator to create a separate JIRA project for all documentation tasks. We, as writers can create documentation tasks in one project irrespective of the product. A few advantages of this approach are:
- Helps maintain and track doc issues in one place
- Run a separate documentation sprint that is in line with the engineering sprint
- Ability to create custom JIRA fields as required by the project
- Makes documentation a more agile process
- Provides managers an overview of the available bandwidth of each writer
To inculcate this process is more of a managerial decision and the following points need to be considered.
- The tickets being created in a separate project, the engineering team cannot view these tasks on their product-specific JIRA board.
- The writer needs to link the engineering epic so that it is listed as a linked issue.
- This process should be communicated across teams so that the engineering team creates documentation tickets in the documentation project.
Conclusion
Every change brings a set of challenges, but a good change is always beneficial. Using JIRA efficiently gives us an edge in bandwidth management. We can take up tasks within a sprint that are doable and deprioritize unimportant tasks. Of course, we should include buffers in our estimation that help accommodate critical issues that require immediate attention. With time, it becomes effortless to manage our tasks using JIRA as it becomes a habit.
"It doesn't matter how successful or unsuccessful you are right now. What matters is whether your habits are putting you on the path toward success." - Atomic Habits
About the Author
Over the course of six years, Akash Jujam has amassed extensive experience in both mechanical and software domain documentation. He has actively contributed to documenting on-premise and SaaS products. His role has evolved over time, encompassing positions as a Technical Writer, Instructional Designer, Trainer, and Project Manager. Akash has conducted numerous webinars and presentations. Currently working as a Senior Information Developer at Precisely, in his daily work, he contributes to content creation, manages releases, and revamps help content.
Current Role: Senior Information Developer
Company: PreciselyCity: Pune, India
Connect at LinkedIn
Indranil Sen
Posted at 17:53h, 04 JanuaryWell written and informative article.