Developing SCRUM Poker with Hasura GraphQL Engine — A time cost comparison

Host your own by downloading the source code @ GITHUB.

During lockdowns and shift toward home office most teams faced a variety of challenges. Since our team is used to SCRUM and doing estimates using SCRUM Poker we wanted to find an online tool for that. Our requirement was that we wanted to just start playing without the hassle of writing in stories and the names of the tasks that we are going to be estimating because that is all done via screen sharing and talking in Teams, Skype and Slack.

A deck of planning poker cards.

We were searching for online tools and none were suitable for our needs because they offered too much functionality which made the app unnecessarily complicated and less user friendly. As we always discussed our projects via conferencing tools we only needed a simple room where you can show the cards to your team and quickly start playing.The basics we needed were:

  • Users can create a room (become admins) and other users can join that room using some sort of code
  • An admin can reveal the cards manually and start new rounds
  • When all estimates are thrown on the table the cards are automatically revealed to all room members

Because the game is simple in its nature, we decided we will build it for internal use. Being early adopters of GraphQL and also partners with Hasura which offers instant GraphQL API’s over PostgreSQL we decided to use the RHC stack (who doesn’t like abbreviations right?).

To explain the abbreviation — our stack of choice — React, Hasura, Caprover.

Because Hasura offers hassle free creation of CRUD (create, read, update, delete) operations and simple authorisation and authentication techniques we decided to keep track of the time spent in order to see what Hasura can actually bring us, time-wise. Next, an analysis follows in each segment (planning, design, development and testing).

PLANNING

Part of each project is the planning phase. 1 man-hour was used to sketch up ideas and draw up some prototypes. We also scheduled one meeting (1 man-hour) to discuss our ideas (this included two developers and the designer).

Because we knew which technologies we would be using, we made a sketch of the database model and defined our entities. For that we used 3 man-hours.

An initial paper protoype for the structure of the app.
Initial mockup screenshot (without design) and some Slack discussion (in Slovene of course).

Total count: 5 man-hours

DESIGN

After an initial sketch was made, we had two design meetings. The initial one (where we were throwing out ideas) and the second one where we finalised the details.

Designing Planning Poker. Not a lot of screens, but still.

Total count: 12 man-hours

DEVELOPMENT

Frontend

For the frontend part, with initial mockups we spent 8 man-hours for the first draft, project initialisation and then 8 man-hours for design changes. Afterwards when the backend models were built an additional 16 man-hours were needed for the logic and testing.

Backend

  • Project setup — the setup of the local environment and dockerization was 3 man-hours (setting up docker compose, environment variables etc.) and setting up the NodeJS service which will handle room joining and creation
  • Hasura — creating the models was easy — from the planning phase we took the model we built (which took 1/4 man-hour to implement in Hasura) and added permission schemas (1 man-hour). Later we added custom actions (that will be triggered on our service) which needed an additional 1 man-hour
  • NodeJS — custom backend logic for adding and creation of the room and JWT token creation, 2 man-hours including manual testing

Infrastructure

We decided to use Caprover for our PaaS provider as it is intuitive and really easy to use. For Hasura we basically just needed to select their image and the deployment was done (including database setup and persistent storage).

TESTING

We didn’t write any tests (because of the scale of the app), we mainly did manual testing in smaller teams.

Total count: 8 man-hours

So, to sum it up the total time spent was 72,25 man-hours. Let’s check out a summary now comparing it to estimates by using a different backend stack (the estimates were based on the initial three features that we wanted to implement in our app).

Using Hasura we reduced the time spent on developing the backend by 85.5%.

Using Hasura was 85.5% faster. Of course there are a lot of presumptions here, the estimates for other stack choices can not be entirely accurate.

We noticed that most of the reduced time comes from the auto generation of CRUD, ready to be used authorizaton mechanisms and having GraphQL as an API which simplified our frontend development efforts.

From our point of view Hasura saved us a lot of time and effort and frontend development was also easier because GraphQL was used as an API.

The source code is available on Github. It is licensed under Apache License 2.0. Feel free to add to it.

--

--

Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store
Boštjan Cigan

Boštjan Cigan

Javascript Engineer @Povio, Professor @ Erudio Izobraževalni Center and Instructor @SmartNinjaOrg