Author: Nils Janse

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 on 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 www.delibr.com

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

Opinions are a wasted company resource!

We all have opinions. And when our opinions are not taken into account we felt not only personally ignored, but also that the company is missing out. But from the employers perspective, what is really an opinion. And when does it make sense to take it into account?

Taking an opinion into account has two potential benefits, insight and involvement. The benefit of the insight varies from basically zero to potentially very large, depending on what decision is being made, and how relevant the insight is. The involvement benefit of taking the opinion into account varies a bit less and depends mostly on how strong the opinion is, and to be frank, also on who holds the opinion. Not taking an opinion strongly held by a key team member into account can have quite a negative impact, and then the benefit of taking it into account is significant.

But taking an opinion into account also has a cost, mainly in the form of time and focus. To take an opinion into account, three things have to happen: it has to be captured, incorporated, and replayed. Capturing of opinions happen either from noting what someone states without being prompted, but often times it requires asking. Incorporating the opinion means thinking through, in a structured way, how it affects the decision being made. Once an opinion is incorporated, it can be replayed to the person who gave it. Replaying an opinion isn’t strictly necessary to take it into account, but without some kind of replay, most of the benefit from involvement goes to waste.

As you can see from this reasoning, taking opinions into account can really be seen as a cost/benefit calculation. So, if it is cumbersome enough to capture and incorporate opinions, it actually makes sense for a company to disregard many opinions. And that pretty much explains why most companies do.

But that then begs the question:

What if it was possible to reduce the cost of taking opinions into account?

That is precisely what we have been working on at Delibr. Our tool allows you to capture opinions in a structured format. It shows what people think, and based on what rationale, and makes it easy to get an overview of the discussion. Our mission is to reduce the friction that comes as more people are involved in making a decision.

As we have seen, if the cost of taking opinions into account were much lower, many more opinions would be taken into account, and that would give companies both better insights and more involvement.

Everybody is a hat-person, but few tools are

The six thinking hats is an excellent framework by Edward de Bono for having discussions that are more structured and balanced.

The idea is that all thoughts and statements can be put in one of six categories. As a pedagogical device, the categories are represented by six hats.

Blue hat – The Big Picture – Thinking about thinking, where are we on the agenda, what questions should we discuss?

White hat – Facts & Information – Identifying and presenting information that is needed, what do we need to know to have an informed discussion?

Green hat – Alternatives and creativity – Coming up with ideas for answers to the questions posed, what if we do it like this?

Black hat – Critical Judgement – Highlighting problems and risks, coming up with cons for different options

Yellow hat – Positive Judgement – Emphasizing upsides and benefits, the good things, coming up with pros for different options

Red hat – Feelings & Intuition – Gut instinct on what to do, either in the early phase of the discussion or later on taking pros and cons into account, what option do you think is the best?

Most discussions benefit from having a facilitator that adds direction regarding what hat the participants should put on.

  • If one option seems too good to be true, the facilitator can say “let’s put on the black hat, what are the problems or risks with this option?”
  • If it seems the team is stuck with two bad options, the facilitator can say “let’s put on the green hat, are there any other options here?”
  • If it is not clear what it is the team are discussing, the facilitator can say “let’s put on the blue hat, what is the question we are trying to answer here?”
  • And so on…

Adding structure, balance, and direction to a discussion can be incredibly powerful, and allow the team to make better decisions, in less time, while still having a high degree of involvement.

But this is a hard thing to do, especially as soon as the group grows beyond 2-3 people. Even for an experienced facilitator, it can be hard, e.g., to tune into whether someone in the group is sitting on a killer pro/con argument or an alternative solution that for some reason is not coming into light.

The mission of Delibr is

to reduce the friction that comes as more people are involved in making a decision

We have explicitly designed the entire tool with the six thinking hats in mind to support this kind of facilitation and make it easier and more effective. All the concepts of the app map directly to the six thinking hats, as per below

  • Questions – Blue hat
  • Comments – White hat
  • Options – Green hat
  • Pros – Yellow hat
  • Cons – Black hat
  • Ratings – Red hat

Because of this, participants are naturally encouraged to engage with all hats, which makes the facilitator role easier. Especially for a team that has used Delibr a couple of times, this can be incredibly effective.