Decisions for Jira

Product bet overview
Plenty of options
Fancy award ceremony
Different bettings modes
Live updates when users take part in the bet

Inspiration

As product people, we work in an environment where people are constantly communicating with each other, whether we are talking to customers or stakeholders within our company. We make decisions based on discussions, data and ideas that others contribute.

Together, we define the roadmap and talk about which features to build next.

Usually, this happens in a regular meeting. Together with the stakeholders we gather around a table and have printed Jira issues with us, which are potential candidates for e.g. the next quarter. Once these topics have been pitched, each person has the chance to vote on the issues (everyone has a defined number of votes). The issues with the most votes win and will be part of the roadmap for the upcoming time frame.

Since Covid-19 the way we work together has changed. Meetings are held remotely and we need to switch from analog to digital tools in order to keep our processes working. How we built alignment with stakeholders was the inspiration for “Decisions for Jira” - voting on issues or better “Bet on the features you are expecting to be most successful”.

What it does

“Decisions for Jira” enables Product Managers to create some kind of a poll about what features should be build next. We define a poll as a betting round, since stakeholders use coins to vote on an issue.

In order to start a betting round, you have to give your poll a title and a description in order to set some context for the people who should vote. For example: “Tell us what to build next” and for the context “We plan to add some features regarding the news to our next sprint cycle. Based on your experience from customer projects - what feature should be part of the next iteration?”

Once you’ve added the basic information, it’s time to select the Jira issues which should be part of the betting round.

screen1

Next to the betting rules: Define how many votes or “coins” (since we see the poll as a bet) each participant has and when the betting round starts and ends.

You can also choose between three betting modes: Default (show names and votes), Anonymous (names are hidden until betting round is closed) or Secret (names and votes are hidden, so no one will be influenced until the round is closed).

screen2

Everything ready? Start your betting round!

Using the Share button, you can promote your poll and send the URL to your stakeholders.

People will see the details as well as how many bets they can place in this round. By clicking on the plus and minus buttons, they place their bet. For sure it’s possible to set all your votes on one issue.

screen3

And the best part of it: You can include this process in your stakeholder meeting and add some interactive fun. Why? The bets are shown live, so as soon as someone places a bet, you can see how the listing changes (based on the betting mode you have chosen).

screen4

When the betting round is closed, the winners will be highlighted, to add some extra sprinkles 🎉.

screen5

Bonus feature: Opening the Product Decision Tab inside your Jira project will show you all previous, active and upcoming betting rounds.

screen6

What problems does it solve

As a Product Manager, stakeholder management is a central part of your daily work. Different people bring different perspectives to a product - including which is the most important thing to build right now. "I think we should build feature A next!", "My customers want feature B", "If we had C, we would make more money" Which PM's are not familiar with such comments? When everybody is working in one place, an established method is a simple stakeholder meeting.

In this meeting, stakeholders share their thoughts, ideas are discussed, and alignment is created. Everyone feels heard and noticed. And the most important thing: There is a place where this interaction takes place.

This alignment is lost in digital-only collaboration. There are video calls in which discussions take place, but there is no tool which handles the specific prioritization - in a way that makes it fun and allows everyone to participate.

That’s why we built “Decisions for Jira”.

How we built it

Obviously we used Atlassian Forge for our app. We chose the new frontend approach Custom UI in favor of UI Kit to adapt the interface to our needs. We used React.js as a library here as it made it possible to use the components offered by Atlassian under https://atlassian.design. In the backend we on the one hand relied on Storage API to persist basic configurational data. For the actual voting information we singled out another approach: When a user votes for a decision this bit of data gets piped through the Atlassian AWS functions into our Google Firestore. We were able to build this infrastructure by leveraging Forges capability to transparently allow external integrations as outlined in the documentation. This unlocked a whole now experience due to the ability to do complex queries and live updates in the UI.

Challenges we ran into

First of all: The Forge development flow was pretty smooth. The development set-up is great. Challenges occurred when we started to build our persistence layer. We had to persist a bunch of voting data when a user takes part in a feature bet. We thought our requirements when it is about a database solution are not that strict. But we figured out that Forge doesn’t provide a persistence that offers queries based on data values and no atomic or transactional operations. These things are needed as we have to prevent falsely duplicated votings, calculate averages and need to sort data based on their attributes values (like for showing the issue with the most votes). Another thing we definitely wanted to offer to our users are live-updates: When something changes, the user should immediately be aware of it as this is Jira Clouds default behavior in boards and issues as well.

After some tries this made us end up with a an approach where we had to integrate our own database. We choose Google Firestore as this database offers the mentioned features. Forges capability to allow external integrations made this possible. At first we had some scruples about that integration because persisting user data outside the Atlassian Cloud felt like bypassing some important part of Forge regarding data residency and security. But we were surprised how gladly Forge handles the external server access from a user perspective when we saw that Jira transparently lists all externals hosts our app has to connect with.

Nevertheless we choose a data structure that easily can get migrated back to Storage Api. Our plan is to remove the external database as a dependency for our app when Forge Storage Api catches up. We are really looking forward for Atlassian next updates there.

We also created FRGE-377 for more detailed feedback.

Accomplishments that we're proud of

From a technical perspective we are proud that we managed it to bring live UI updates to our app. This is something users are already used to on Jira boards and other views: When something changes on the server, the UI immediately updates. This is not an easy task with the given APIs. Connecting another database in a way that we can easily migrate back to an Atlassian-Cloud-only approach was tricky but we are happy to got it figured out. From a product perspective we are actually proud to have identified a real problem of our daily work and made its solution become a usable app. Building it for Codegeist was a lot of fun.

What we learned

We learned that Cloud development with Forge can sometimes be challenging. There are limits which exist for security reasons which makes totally sense. This somehow makes it necessary to re-think some feature ideas you have during development. Compared to the on-premise development it was uncommon that we can’t control the whole Document Object Model. Forge does a great job when its about to make an app look live a native integration even it is within an iFrame. After all we learned it is worth to start building with Forge even if some features are still missing because updates come up nearly every week.

What's next for Decisions for Jira

We are happy to participate in the Codegeist 2021 and pitch our idea of “Decisions for Jira”. We have a lot of features in our backlog that wait to be implemented like a comments functionality and other betting modes. We are looking forward to get some feedback and improve our app. We want to simplify the way decisions are made and create alignment between product managers and stakeholders.