Sprints

🏃 One sprint is two weeks long.

Releases

We have a big release at the end of each sprint where bigger stories developed in the sprint go live. We also have multiple releases during the sprint as well where we might release smaller issues, more urgent fixes or any story that can be released independently without waiting for the end of the sprint.

Sprint work will revolve around well-designed and groomed stories that enable new functionality on the platform. The whole team refines stories together with the dedicated Product Manager who has the end goals and business requirements in mind. Then the engineers and QA help put all the details together, and decide how to solve the problem and how hard it is to do.

Some of the sprint work also goes into refactoring if we think it’s required to enable some new functionality or make our life easier.

Hacking

💻 We hack things in time-to-time, which can end up as part of the product and an architectural or structural change. Sometimes, we just abandon things that simply don’t work!

⏳ Things change so much in the tech world that we may need to build parts of the product from scratch…and that is fine! When we build something, we build it for what we need at that moment or in the next few months, rather than building with the next three years in mind. We’re all in a constant state of flux and the product needs to adapt to the ever changing needs of our clients.

Rebuilds

🏗️ We have had at least four major rebuilds and a whole lot of smaller ones in our six-seven years history so far. (Like the Matrix) 😎.