Let's Play Poker (Planning)

At marmelab, development teams collaborate using a scrum-like agile process. But in the team I currently belong to, we encountered some difficulties with our planning poker event. The team mixes home and office workers, and synchronizing our estimations through a webcam was always a source of confusion for everyone.

So, one day, someone just asked:

• Why don't we build a tool for that?

And, like any good web developer, I just thought:

• Yes, let's start another custom project on this!

What Is Planning Poker?

To start with the basis: playing Planning Poker is not like playing Poker.

The planning poker is an optional part of the Scrum] process where the development team, and especially the developers, try to estimate the complexity of new features. Based on these estimations, the team can decide more precisely the scope of the next sprint.

It is called "poker" because it is usually practiced by playing cards. The value on the card indicates the estimated complexity of the feature that is estimated. Usually, the cards follow the Fibonacci suite: 0.5, 1, 2, 3, 5, 8, etc. For a given user story, each "player" has to choose one card secretly, and all players show their card at the same time.

If all players agree on an estimate, that's the estimate given to the user story. Otherwise, developers must discuss to reach a consensus. Usually, the developers who chose the largest estimate have to discuss their point of view with the ones with the lowest estimate.

The "secret" part of the vote is important for the "players" not to be influenced by each other in their estimation.

The process is repeated for each feature.

Requirements For A Planning Poker App

To make this planning tool fully functional, there were some mandatory constraints to implement:

• Any person should be able to play, no matter if they are in the same room or not
• No one should see the votes from other players before they send their own
• No one should be able to change their vote after sending it, but people should be able to change their vote before sending it.
• It is necessary to be able to chain several votes

Beyond that, I wanted the game to be really easy to start. No inscriptions, and no waiting line.

And eventually, I wanted the tool to use peer-to-peer connections. It was something I wanted to experiment with. And this tool appeared to be relevant for this use case.

Many nice planning poker tools can be found online that meet some of my requirements, like parabol or planningpokeronline for instance. But most of them require a subscription, a payment or use advertisement. And where would have been the pleasure to build my own?

Introducing PeerJS, A JS P2P Library

For the core of the communication, I chose to use peerJS. This peer-to-peer communication library uses WebRTC and provides a nice, well-documented API. I also checked freedomjs, but it looked more complex than PeerJS.

With PeerJS, I can manage the connections using a single object:

const peerManager = new Peer(anyFreeUserId, CONFIG.peerJsRegistrationServer);

And only 3 event functions:

peerManager.on('connection', conn => {
    //A connection is received
    conn.on('data', data => {
        //Some data are received
    });

    conn.on('open', () => {
        //The connection has been opened
    });

    conn.on('close', () => {
        //The connection has been closed
    });
});

After this initialization, the rest of the job consists of managing the messages themselves. As expected, this library is very simple to take in hand. A pleasure to implement.

With this system, I managed to build a planning poker app with nothing more than a web page and a registration server. This server is used to connect users to a team but is not used anymore after joining a game.

The transferred data have to be serializable. So any JSON object will fit. You just have to manage the various kind of communication by decoding the data object and by running the corresponding action (for instance: {card: "XL"} to play a card).

PeerJS also provides its own registration server that lets you start locally with nothing else than a browser. During the development, I experienced a server crash only one time.

Their doc even explains how to build a registration server using ExpressPeerServer or PeerServer.

Note that peerJS also provides video and audio connections, but that was not in my scope.

The Result

The Good, the Bad, and the Optimizations

Number of Players

Using this peer-to-peer system for organizing poker planning has some limits. The number of direct connections for a player will grow exponentially with the number of attendees. For small teams, it's a good fit. With 2 developers and one scrum-master (3 attendees), each participant has only 2 peers connected, which means 2*3 = 6 connections.

But for big teams of at least 6 attendees, for instance, this number grows up to 5*6 = 30 connections.

Also, Chrome starts to warn users about performance when the number of simultaneous WebRTC connections exceeds 3.

By the way, to connect all participants, I had to implement a complex mechanism where each person had to send a list of their friends to the others. This allows everyone to connect with everyone. It was fun to code, but definitely not optimized.

To limit this problem, one solution is to centralize the communication - one of the participants has a special "host" status. The person who chooses to "host" the poker planning receives the messages of all attendees, and then, resends these messages to all the other attendees. By doing this, only the host must have a large number of WebRTC connections. The total number of connections for 6 people will reach at most 5+5 = 10.

Mobile UI And Responsiveness

Having a mobile version was very important to allow people to play while sharing a video conference on one computer in the same room. In this case, one (probably the ScrumMaster) can play on the computer, and the others can play on their phones.

The design to keep viewing all the cards on mobile wasn't that easy. And it can surely be improved still. But currently, it does the job.

Storing Data

Currently, all data received by a participant stays in memory.

One of the next upgrades should be to keep track of the information in the storage of the browser. It can be fastidious to repeat information each time after closing or reloading the page. But no real difficulty here.

Try It Yourself

You can test the demo poker planning site Plokering.

Keep in mind that this work is still in progress and subject to change.

As always, all the sources are free on GitHub at marmelab/plokering

This article is guaranteed 100% ChatGPT free. :)