Continuing our look at the output of our internal hackathon, László and I (Damián) decided to build Radix Planner, a project to allow for remote planning poker (also known as Scrum poker) running on Radix.

What is it?

Planning poker is a gamified technique that is useful for estimating the effort required to achieve different activities and stages of software development. If we were all sitting around a table, we would typically write our estimates (or use numbered cards) and place them face down. Only after everyone has submitted their estimates are the cards revealed and the time effort estimated as an average.

It is useful to operate in this fashion so as to avoid the cognitive bias of anchoring, where the first number spoken aloud sets a precedent for subsequent estimates.

How does it work?

The Radix Planner DApp operates through a client front-end, with the results stored on the ledger. The DApp, although obviously basic, allows users to submit a vote on a User Story. Once the vote has been logged, the page updates to show the current votes for that story as shown below:

The votes are recorded to the ledger through the Radix messaging system. This allows messages to be transmitted from one account to another or enables a non-user account to be set up which lets users send and receive messages from the generated messaging group. For the purposes of Radix Planner, the votes were sent as JSON-strings from a user account to an account that was registered as the voting address for a particular user story.T

here are a number of things we would like to have done that could add to the DApp, in addition to using wallets instead of email addresses. To make it more user-friendly we could have built-in features such as vote editing or multiple votes, allowing for users to change their mind. There is also the potential to integrate it with Atlassian’s Jira, in order to automatically import User Stories so that they can be voted on more easily.From a development perspective, we could have used tokens rather than messages to transmit and store the votes.

This would allow for tokens to be automatically generated when a user votes. Furthermore, we used email addresses as the basis for the user account. However, due to time constraints, we didn’t build in username or password validation, meaning that users could be impersonated. To address this, we could either have used UniqueID’s or have switched from email addresses to private wallets as the seed for the keys.

Use cases

The key aspect of the hackathon was to understand how we can build applications which utilize the Radix stack, but which also feature concepts that could apply more widely. There are countless polls and surveys that are run every day, and while ones taking place in small trusted teams might not need to be stored on an immutable ledger, there are some surveys where it certainly would be useful to have a complete and viewable record of voting history.

There are also some situations in which people wish to vote anonymously but without wanting anyone to be responsible for collecting the votes.Furthermore, the features of Radix Planner (such as the voting mechanism) could be used for other DApps running on Radix.

This includes the likes of gambling, a popular DLT activity, and governance.Note: As this project is built to interact with the internal betanet, we will open-source it only after the public betanet is live. Have questions? Message me or László on the Radix discord group, or you can ask them in our telegram channel.Join our mailing list to get notified when we hit major milestones - Subscribe Here!