Category: Agile

Aged paper map

JIRA is in desperate need of refinement

An article by Jon Evans titled “JIRA is an antipattern” recently became the number 1 on Hacker News with 360 comments (and counting). The main point of the article is that JIRA is being used in the wrong way, and that product teams should complement its use by also writing documents. As indicated by the title of this article, although we agree with the main point, we would prefer to defuse the explosive original title somewhat.

For us at Delibr, this is of course very exciting, as the interest in the article shows how relevant the topic we are working on is. As we perceive the article to be so relevant, we decided to write a reply to it. It is written so that you can read the original article and our reply in any order.

Our reply:

We’ve just spent a year interviewing 200+ product owners about the problem that you are describing. For most teams, JIRA works great for monitoring progress on closely defined tasks, but context “above story level” is a real problem. The better teams do already use another tool than JIRA to write such documents, typically at “epic level”, and typically using Google Docs and/or Confluence.

But almost all struggle with writing this document, where common problems include:

  • duplication of work and manual updating between the document and JIRA
  • unclear handover of the source of truth, since things that are written in the document are “true until stated otherwise in JIRA or a JIRA comment.. or somewhere on Slack”
  • lots of input/questions/decisions from refinement meetings not captured in either the document or in JIRA

I think the solution is to think of this document less as a “requirements document” (many label this doc “PRD”), and more as a “refinement document”.

This “refinement document” should

  • try to capture the conversation that happens in refinement meetings
  • involve also the developers to cover not only “why” and “what”, but also a bit of “how”
  • evolve and be updated all the way through development as new insights are gained
  • be the source of truth and available to the developer working on the JIRA issue

We have made a tool specifically to support working this way with “refinement documents”. One dedicated place to refine features. Structure, collaborate, keep track of questions and capture not only decisions, but also conversations. Seamlessy transform your work into crystal clear Jira epics and stories. When you turn notes into Jira issues, you can see all the details via our Jira plugin. Happy to hear your thoughts, please do check it out at

POs should write explicit questions with decisions to structure the conversations around new features

This is the second article in a series on how the best Product Owners manage to get on top of their refinement process. The insights come from interviews and close collaboration with ~150 product owners from across tech.

A Product Owner is responsible for the 3Cs, Card – Conversation – Confirmation.

Most POs share the Card (story ticket in Jira) and the Confirmation (written acceptance criteria and/or attached reference designs) with their developers.

In an ideal world, the developers should also have been part of the Conversation, or at least the PO should have shared it with them, as that would provide them with relevant context, empowering them to make sound judgment calls and removing the PO as a bottleneck.

But oftentimes the developers have not been part of the whole Conversation. And in sharing it with the developers, the PO faces the problem that the Conversation does not naturally occur in a format that is easily digestible. The discussion that lead up to a decision is instead often spread out across many emails, chat threads, and meeting notes – if it is at all written down.

As long as this is the case, it is not feasible to share the Conversation, as it could take hours for a developer to go through it all, and even then, it might not be possible to extract sufficient context.

That is why many POs only share the Card and the Confirmation with their developers.

But the best POs make an effort to have a condensed representation of the state of the Conversation. In its most simple form, this is something that all POs should do. They should have one place for notes relating to each story, a shared living document or maybe an area on a wall.

Some POs attempt doing this by writing neat documents with formatted text in full paragraphs. But it is unnecessarily hard and time-consuming to try to capture the discussion and formulate the rationale for why a decision was made in that way. The result of this tends to be long and complicated sentences containing “based on”, “having considered”, “on the other hand”. This is a wholly unnecessary effort, as these sentences are not only hard to write, but also hard to read.

We believe that POs should instead use a bullet outlining tool, to structure the conversations around new features, and simply write down questions as bullets, with options as sub-bullets, and pros/cons below that. That way they can get maximum speed and simplicity by formatting neither text nor grammar.

Once they have that structure, they should be vigilant to continually capture and add whatever questions are raised that is related to that feature and also fill in different discussed options, pros, and cons – and of course decisions made. These should be added, not as full sentences and paragraphs, but as concise and to-the-point bullet points.

This way is not only faster to write, but putting the Conversation in this format also makes it much easier for the developer to digest.

The format is also easy to digest for the stakeholders, and so allows the PO to assign and follow up on specific input, (LATER: not to mention, it will also save the PO a lot of time in the end).

Delibr is an outlining tool for product owners that helps them handle the conversation around new features.

It aims to help POs bring structure and cohesion to a conversation that is often disjointed and split across email/chat/meetings by explicitly capturing questions with decisions.

Conversation is King, Product Owners Ignore This at Their Peril

This is the first article in a series on how the best Product Owners manage to get on top of their refinement process. The insights come from interviews and close collaboration with ~150 product owners from across the tech industry.

In Scrum, the PO’s responsibility is to manage the product backlog – to handle both prioritization and refinement of the items therein.

We believe the Three C’s framework by Ron Jeffries is a great way to describe the role of the PO:

  • Make sure the team works on the right things, typically expressed as stories, each written on a Card
  • Make sure the team and relevant stakeholders share enough understanding and agreement on what these stories mean, by facilitating a Conversation
  • Make sure this conversation is translated into concrete acceptance criteria and/or reference designs so that it is easy later to get Confirmation whether the story is done

The ideal scenario would be for the PO to get team and stakeholders in the same room, write the Card, have the Conversation and coming up with the Confirmation. However, in reality the Conversation happens in several iterations with different constellations of stakeholders and team.

And so most POs handle this by moving emphasis from Conversation to Confirmation. They add user stories to Jira (Card). Then they write acceptance criteria and attach reference designs to these (Confirmation). Often this works quite well.

Except it turns out that sometimes it is really hard to make sure everybody is on the same page, and so they become the bottleneck by virtue of being the only ones who were present when all conversations took place and so end up spending a lot of time handling additional meetings and back-and-forth communication.

Leading up to the interviews we let POs fill in a survey on how they work. One part of that survey focused on handling the Conversation and asked how often they experienced different types of problems.

It was clear to us, both from the survey, and from following interviews and collaboration, that these and adjacent problems cause a lot of lost time but also other issues relating to output quality and team happiness.

As we had further discussions with the survey respondents, we saw a pattern among the POs that expressed the least amount of these problems. They placed great emphasis on facilitating the Conversation. Specifically, we saw that they engaged in three practices:

  • They made an effort to keep a structured representation of the current state of the Conversation
  • They were diligent about asking stakeholders and team for specific input to the Conversation, and about following up on that input
  • They did not stop the Conversation when development began, but assumed new input would come up and so ensured continuity

By engaging in these practices, these POs managed to overcome the problems that other experiences. In the following articles, we will elaborate on these three practices. Next article in the series explains why product owners should write explicit questions to structure the conversations around new features.

Delibr is an outlining tool for product owners that helps them handle the conversation around new features.

It aims to help POs facilitate the conversation by enabling structure, follow-up, and continuity