3 Jira Tips for Product Owners You Should Know

With the agile product framework Scrum, the role of Product Owner also emerged in the project management business. This article contains 3 Jira tips for Product Owners. If you are in the role of Product Owner using the project management tool Jira, this article in our series on Jira software is for you.

Look forward to the following topics in this article:

• Responsibilities of a Product Owner
• Tip 1: Writing Stories that will not last
• Tip 2: Acceptance criteria for good Stories
• Tip 3: When it is getting too much: split Stories
• Conclusion

However, before starting on the responsibilities and tips for the Product Owner, it makes sense to get an overview of the different Atlassian Tools. Let us clarify first what Jira and Confluence are.

What Is Jira?

Atlassian Jira is a web-based tool for work management, project management and defect tracking. It is mainly used by teams in product and software development. It supports agile teams with different project and board types, for example:

• Kanban
• Scrum
• Project management
• etc.

Interested in learning to use Jira? We offer online company seminars in English.

What Is Confluence?

Atlassian Confluence is web-based Wiki software supporting internal collaboration in project teams and companies. The tool integrates with Jira perfectly. In this combination, it provides the best conditions for agile teams.

Why Have Special Jira Tips for Product Owners?

By now, the role of Product Owner is used in many projects – even those not based on the Scrum framework but merely using some elements of it. The scope of the Product Owners’ tasks differs from company to company, since Scrum is not used as a consistent basis.

Jira, on the other hand, is a work management software used by 14,000 Atlassian customers worldwide. Consequently, it is widely used, both in traditional constellations and in modern project management organizations.

As a Product Owner, you can hardly get around the use of digital tools nowadays. Jira being the current world market leader for work management, we will concentrate on tips for using Jira in this article.

You might also like our article about the Role of Product Owner in Agile Teams.

Responsibilities of a Product Owner

As mentioned above, it varies from organization to organization what tasks a Product Owner takes on. However, the following tasks are often part of the responsibilities of the role:

• Recording and coordinating requirements
• Representing stakeholders in the team
• Communicating internally and externally
• Product and project marketing
• Defining the roadmap
• Describing WHAT is to be implemented
• Prioritization and budgeting
• Focusing on product development and integration into corporate strategy

Most of these points can be implemented with the aid of Jira. The focus of Jira is on formulating the requirements and creating the roadmap.

Now look closely at the list once more. Do you notice anything? There are hardly any differences between the requirements for the Product Owner and the role of project manager. However, the focus in this case is more on the project and its successful implementation. This is different for the Product Owner: the focus of the role is on ensuring that the product is successful in the long term and that it fits the overall strategy of the company.

Find out how project management with Jira works in this article.

3 Tips for Product Owners

Recording requirements, describing the WHAT, prioritizing and creating a roadmap: all of these are tasks you can map in Jira as a Product Owner. And even if you do not do this yourself but have delegated the task to the team, the following tips are bound to help you.

Tip 1: Writing Stories That Will Not Last

Writing Stories in Jira is very easy. Yet, the challenge is to write good Stories that the team will understand and that include what the stakeholders want.

Therefore, why write Stories that will not last?

A Story serves only one purpose: implementing a requirement or a request. It is not designed for documentation, though it is used for documentation in some companies.

What Are Requirements?

Requirements are functional and non-functional specifications, requests and ideas. In most cases, the requirements are unclear at first and develop over time. Once they are specific enough, they can be recorded as a Story in Jira.

Where Else Are Requirements Described?

As a rule, you can always use Stories.

However, it can also make sense to describe requirements in Confluence first and then align them with the stakeholders. Subsequently, one or several Stories are created from one requirement. Jira lends itself as a tool for this. Yet, it is important to remember linking the Stories in Jira with the requirements in Confluence.

What Are the Benefits of Using Confluence?

If you describe the requirements in Confluence, you have also found the appropriate location for documentation. Confluence works better for structured storage of information. Jira is short-lived. Once a Story is completed, it disappears from the visible area and must be searched for to become visible again.

How Can This Be Further Structured?

By default, Jira works with so-called Epics. An Epic is a big Story. In Jira, this is depicted as a structure element. Under an Epic, you can subsume several Stories. The structure of the requirements can look like in the following example.

The structure usually looks like this:

1. One to several Epics can be created from a requirement in Confluence.
2. Under an Epic, there can be Story, Bug and Task.
3. Stories and Tasks can again be divided into Sub-Tasks.

How Are Stories Used?

Stories are used to describe customer benefits. Over the last few years, a template has been established for describing User Stories:

As a [role]I want [feature]so that [value].

Example: As the author of the blog post, I want to convey the writing of Stories so that Product Owners are supported in their daily work.

How Are Stories in Jira Presented?

Three fields are mandatory in Jira: Project, Issue Type and Summary.

The template mentioned above is entered in the “Description” field. For our example, this means:

However, the introductory text alone will not be enough to implement the Story. In the case of the blog post, we still need:

• Keywords of the post
• Length of the post
• Images of the post
• What tips should be described

This means, as a Product Owner, you have to provide additional information to describe the Story. To achieve this, you can just add further information in the Summary or as an attachment.

One way to enter further information is in the form of acceptance criteria.

Tip 2: Acceptance Criteria for Good Stories

The acceptance criteria have been added to the example described above:

In the example, three acceptance criteria have been recorded in the Description.

• Writing Stories, acceptance criteria, and splitting Stories have been described
• Post length of about 1,500 characters
• Paragraphs do not exceed 3 to 4 sentences

As an alternative to entering the criteria in the Description, you can also use a To-do plugin. In this case, the acceptance criteria are presented as individual entries that can also be ticked off.

 

Tip: A suitable plugin for recording acceptance criteria in Jira is e.g. Acceptance Criteria for Jira by HeroCoders.

To start working with acceptance criteria, however, the Summary field is sufficient.

Tip 3: When It Is Getting Too Much: Split Stories

Even when using the hierarchy described above, some Stories will be too big. But what exactly does too big mean?

If a Story is too big, it will not be possible to implement it in a reasonable timeframe. Likewise, estimating its effort or complexity will be difficult to impossible.

If you are a Product Owner working with Scrum as a framework, your benchmark is a Sprint. A Story should be described in such a way that it can be implemented within a Sprint.

Interested in Jira tips for Scrum Masters? Read article Jira for Scrum Masters.

If you work without Sprints, you can work out with your team how extensive a Story should be at maximum. Most teams agree that Stories should be completed within 2 weeks.

How Do I Split a Story in Jira?

To split a Story in Jira, you can use the split function. Right-click your Story in the Backlog, and then click Split issue in the context menu that opens.

As a result, the below dialog box will open:

For our example, we want to treat proofreading (“Korrekturlesen” in the example) and publication (“Veröffentlichung” in the example) in separate Stories. Both Stories include further tasks. For instance, publication also involves adding links to the blog post and including the post in the page structure.

For our original Story – creating the blog post – this is no longer relevant. We can consider the creation of the post as done, even if the blog post has not yet been published.

This is how you can divide a story into meaningful sub-steps.

How Can the Story be Split in a Meaningful Way?

In the previous example, the division was made from a logical point of view. We have three Stories based on the publishing process:

• Writing the post
• Proofreading
• Publication

However, writing the post could also have been split into several Stories. For example, into:

• Writing the introduction
• Writing of Tip 1
• Writing of Tip 2
• Writing of Tip 3
• Integrating the images
• Writing the conclusion

This would have been a division into individual work steps. This is, for instance, an option when different teams are working on a Story. Or when a part is planned for one Sprint and the rest only later. In this way, the post could be created over several Sprints, and the Stories could be completed individually.

The Story could also be divided functionally, e.g.:

• Writing a post with tips for Product Owners
• Research for suitable images

In this case, the Story is split into the actual writing and the image research. Applied to a software project, this would mean:

• Implementing the backend functionality
• Implementing a frontend to operate the backend

As you see, there are many ways and possibilities to split a Story in a meaningful way. Discuss with your team what would work best and be most helpful for you.

How Are Dependencies Presented?

If you have split a Story, this is visible in both the original Story and the new Stories:

Via the Board configuration, you can also display dependencies in the Backlog (or even on the Board) in text form. To do this, got to the configuration (Board Settings) at the top right:

Go to Card layout (1) and then add “Linked issues” to the Backlog view (2). Please do not forget to click on “Add” (3) as well.

If you return to the Backlog now, the dependencies will be displayed below the Summary.

Thus, you will see the dependencies of Stories in text form below each other.

Conclusion – Using Jira as a Product Owner Is Easy, But …

The tips mentioned above make it easy to use Jira as a Product Owner. Stories are quick and easy to create as well as structure. In combination with Confluence, requirements can be recorded in a transparent and sustainable way.

By describing the acceptance criteria, it becomes clear what a Story must contain. And if several people are working on a Story, or a Story simply becomes too big, there is an easy solution: simply split it into several Stories.

Yet, as with many things: the devil is in the details.

Are there any Jira tips for Product Owners which we have forgotten? In that case, please write to us in the comment area.

print this article