Scrum Planning Poker Tool - Sneak Preview

Do you remember the cliffhanger from my last post? It was about an online Scrum Planning Poker tool providing the functionality to commit the estimations directly to Jira.
Jan Nabbefeld

Do you remember the cliffhanger from my last post? It was about an online Scrum Planning Poker tool providing the functionality to commit the estimations directly to JIRA. Maybe this sounds like overstepping the mark, but it would make our life much easier as we have sprint plannings every two weeks with our two near-shoring development teams. The tools we used so far, forced the whole team to keep two browser windows open at the same time: JIRA to have a look at the description and comments of the issue the estimation is about, and the Scrum Poker tool itself to vote for an estimate. The Scrum Master needs to handle the Poker Round and commit the result to the particular issue after every estimation round. To be honest: it worked out so far, but the situation wasn’t ideal. We decided to improve the situation.

Scrum Poker Planning Tool Recipe

What will be needed to develop a tool that makes online Scrum Poker Planning sessions easy? Which features should such a tool offer? First of all, I think one would need a web application that implements the following process:

  • The tool must provide dedicated poker rooms to be shared with a team.
  • One of the “players” creates the room and represents the “JIRA master”. It is on him to handle different poker rounds, which actually represent a sequence of JIRA issues to be estimated.
  • The issue key and description of each JIRA issue should be visible along with the deck of planning poker cards.
  • There are different numbering scales for Planning Poker cards, like Fibonacci or standard playing cards. We want them all in the tool.
  • Every participant should be able to see the covered cards of the other teammates that get uncovered once everybody voted on a particular issue.
  • It should be possible to participate in a Planning Poker session without being an active “player”. This is interesting for Product Owners or the customer who attends the session as a watcher.
  • At the end of each poker round, the result based on the estimate of each participant should be calculated. The “JIRA master” should have the possibility to override the result manually by the (1)
  • Finally, the estimation can be stored in the JIRA issue.

Scrum Poker Planning Tool Ingredients

Implementing such a tool must be fun for the one who is doing it! It shouldn’t feel like back-breaking work to be finished in a minimal time. In fact, it should give you the chance to dive into new technologies that can be beneficial in a commercial context. A space odyssey that widens your horizont -Meteor (2)! Seriously: this platform provides everything that is needed in order to build a web application handling user interaction in realtime. Client and server-side part is pure JavaScript based on Node.js and a bunch of additional packages.


We gave it a try. Check the beta version at This version implements a basic set of features as defined above. It must be said that the JIRA communication is handled by the server part of the application. The reason is the cross domain policy of JavaScript. There is no way to handle that inside the browser connecting to the Meteor server at the same time. Although HTTPS is used for the client-server-communication it doesn’t kill the pain as one has to send the JIRA credentials over the wire. JIRA is using cookie sessions to set up a communication channel so it needs to be send only once. We thought about alternatives to overcome this architectural disadvantage like using OAuth (admin permission is needed to add a client to JIRA) or providing a local reverse proxy application (not working out-of-the-box without configuring JIRA accordingly) but it doesn’t solve the problem entirely.

scrump poker

Finally we found a way to overcome the problem and implemented a small desktop application that remote controls the Meteor web app and handles all JIRA related communication itself. To make use of that from all common OS platforms (Linux, OSX and MS Windows) we use node-webkit as a container. As soon as this part of the project has left the alpha status we will release it, and remove the current server side JIRA communication from the Meteor app.

After planning our sprints using the tool, we want you to use for your planning sessions. The JIRA connector feature is optional. We tried to make the design responsive, so that it can be used from mobile devices as well. The software isn’t entirely ready yet, and a lot of other additional features are on the roadmap. Release early, release often is part of the agile mythology and we stick to it. This is an early release, however, and we’ll try our best to add more features in the near future (like the remote control app (3) mentioned above).

Have fun using it, and please tell us what you think about it.

  1. In theory, all participants of an estimation round should agree on one result by voting the same number within the round. In my experience this is often the case but repeating the round over and over again to end up with the same number prolongs the planning session for no good reason. People can agree on one result most of the time by simply discussing the technical problems and agree on the same number.

  2. Wasn’t that poetic?

  3. Actually it works already, but as today is the last day before my (well deserved) holiday I won’t release it yet.