CryptoScrum

QR Code for SLP address qzqn399ljyt6zv5mvas4ecmt3k2xmjgway7rrh0x5j
main view of the backlog management tool
my new friend Electrum :-)

Inspiration

Hello, my name is Eva and I am a Product Owner :-)

I've loved it at times, when everything is well oiled and things work out, but nothing makes Scrum and Agile more loathing than unclear priorities, changes of mind and heart, lack of communication between team members, and above all, failed sprint demos. (no, it's not the yellow sticky notes!)

So why don't we try a fun and rewarding way to elevate sprint demos to something to be looking forward to, instead of the soul-crushing meeting where sticky notes swap columns and blaming fingers are pointed at each other? Let's use crypto too, not only because it's fun, but because nothing beats experience when it comes to climbing the learning curve. It might also be a great way to get your Product Owner educated and who knows, maybe she will convince the business stakeholders to bring stuff that could be built with it into the product backlog?

And thus, CryptoScrum is born.

What it does

We start with a tool to be used to manage the product backlog, and two Scrum ceremonies: sprint planning and the sprint demo. This might be be JIRA, AzureDevOps, even just a Trello board.

Let me quickly define some key terms. If you know the lingo, skip the next paragraph!

[Start of Scrum terminology]

A user story is a unit of functionality that can be fully implemented (and tested, and documented, and deployed in production) in a single sprint. If your user story will take longer, then you'll have to split it. A sprint is a fixed period of time (one or two weeks typically) that starts with a planning session and ends with the sprint demo. During the planning session, the Product Owner decides what top priority user stories will be worked on during the sprint. The whole team, together with the PO, discuss these user stories one by one. Once they are fully understood, each one is assigned story points, which represent the effort required to fulfill the user story: documentation, development, tests, deployment, though not necessarily in that order. Last but not least, each member picks a user story they will start working with (and once it's finished, they'll pick another one from the sprint). Each team has a certain velocity, that is, the number of story points that they usually can cope with in a sprint. A sprint should not be overloaded, that is, the team should not accept more user stories than they can deliver. A failed sprint demo is one where the product owner does not accept the implementation of the user stories contained in the sprint. There are many reasons for this failure, but in my experience the most common ones are: miscommunication between the team and the product owner; priorities were changed mid sprint; a disgruntled team member has sabotaged the sprint!

[End of Scrum terminology]

If you are a startup or a group of people working towards a common goal and you wish to implement a fair way of distributing the gains of the joint effort, then you will probably want to implement a DAO (Decentralized autonomous organization). You write some smart contracts that link future rewards to completion of tasks and voilà! Justice delivered via crypto in a timely basis.

My proposal is for a more traditional environment: developers, testers and product owners who are regular employees, whose main source of income is their salary, and where effort and rewards are not tightly coupled (yes, there's an employee appraisal at the end of the year, but individual efforts are diluted in a myasma of other variables used for bonus calculations). So here's what I propose.

Management allocates a bounty for a successful sprint at the beginning of it. They decide how much this is - if we're close to an important deadline this could be more, or it could be random, etc. A few BTC or a few Satoshis!
We calculate how much a story point is worth by dividing the bounty by the number of story points included in the sprint [well, a little less, because we have to allocate some reward for good Product Owners that communicate well and cooperate towards successful sprints]
We generate a Smart Contract per user story. In it, we promise that if the user story is accepted during the sprint demo, the equivalent monetary value of its story points will be transferred to the team member that picked the user story, and a certain, smaller percentage, to the Product Owner too.
Failed user stories see their corresponding smart contracts vaporised.

This of course would be automatic upon creation of user stories in the product backlog management tool (JIRA, etc.) The only extra, manual step would be that initial allocation of the bounty for the whole sprint.

How I built it

Ideally I would deliver an integration with one of the product backlog management tools stated before, but that's too much. So I will build a simple app that can be used to create a sprint, allocate its initial bounty, addition of user stories with their description, allocated PO, allocated team member and story points, and the ability to accept or reject a user story.

Then I wrote a simple tool that writes up the relevant Smart Contracts in Cash Script syntax; launches transactions for their creation, execution, or cancellation. Each of these actions will be triggered by the corresponding events of the product backlog management tool just described.

Everything licensed under Apache 2.0

Challenges I ran into

Steep learning curve and a few suboptimal decisions were most challenging. First of all I decided against using React, Vue or any other framework because it was something easy. Well, I ended up implementing state management by hand. jQuery is fun - but never again. I also decided to build on Windows 10 and not use the WSL. Many hiccups on Windows.

Working with so many new tools was interesting too. CashScript is quite straightforward. The bitbox-sdk would not get installed because of npm ERR! Unexpected end of JSON input while parsing near '...hHaj+c0sIgaAnIAcm69Lj' (friendly!), so lots of activity with the wallet applications. Electrum for Windows doesn't have a working CLI (tip: use Windows git bash to bypass this, I swear!) and Electron triggers all the red warnings, not very much liked in Redmond.

But I've learnt so much, it's all worth it!

Accomplishments that I'm proud of

Being able to handle so much information and actually get something done in such a short timeframe!

What I learned

Getting the gist of how everything works is the fundamental element. As for individual tools or technologies, BTC related, CashScript, the network providers, the myriad wallets, but Electrum I've fought with the most, different types of addresses, encoding versions, and a master's degree at bitcoin.stackexchange.com