Make it available

Although sprints aim at adding something new to the product we're working on, we don't necessarily need to wait for it to end to have a formal release event. We follow a set of procedures that help us ensure that we are ready to make a given piece of functionality available to users. This includes reviews made by peers and a careful development strategy that allows us to be flexible when we need to decide what to release.

Check the Delivery guide

Code review

All code that is made by engineers is reviewed by other engineers at Catalpa. This is an industry common practice that helps preventing bugs and inneficient code to be integrated in our products. It's frequent for the reviewer to request changes and only after those are addressed can the code be part of a release candidate.

Visual review

As soon as the engineering team has a release candidate ready and published on a test server, it can be reviewed for functionality and visual implementation. It's the moment were we do a final check on how things look and feel before it can be released. This includes double checking that all the User Stories are delivered in full, making sure all conditions of satisfaction are met. It's also the time to ensure that everything looks exactly like how it's been designed (colours, margins, font sizes, etc.). As soon as the reviewer approves the bundle, it's ready for deployment.

Flow management

There is a number of conventions we like to use that make our work transparent to the team. Instead of spreading information across tools, we accomplish this by using the resources that Github provides. It's a simple yet efficient system that, if followed, can bring reasurement to everyone.

Milestones

Everytime a new Epic is about to start, we create a new Milestone on the project's Github repository. It will contain all issues related to the Epic and it's a simple way of tracking global progress.

Issues and labels

Issues can be User Stories, bugs, tech issues or just about anything we want. What makes it work for us is a small number of rules we follow to make sure that we know what we're looking at. It's all about using Github labels.

Issues labeled as "user story" are copied from the Epic Design document and are considered to be top-level, meaning that all other issues will eventually be related to them. They usually progress slower than non "user story" issues and represent work that can be assigned to several people.

Issues labeled as "tech" are usually a part of a User Story that was assigned to a single developer. When created, we add a link in the description referring back to the User Story they belong to. There are usually many of these per each User Story and they tend to progress faster.

Issues labeled as "bug" are usually created as a result of a visual review where the reviewer found out that conditions of satisfaction where not met or that some functionality isn't working properly. These are usually also labeled with a version number.

When all associated issues are done, the User Story can be considered as being complete.

Versioning

One thing that allows us to be flexible when we need to release new functionality is to clearly know when we are ready to do so. We plan sprints so we can deliver logical pieces of functionality but it's not uncommon to find moments where unexpected problems occur and need to be fixed or where the work to be done simply takes longer than expected. So, instead of waiting for everything to lign up and be ready, we identify which pieces are of higher priority and can be released earlier. To help with this we use predictive versioning and label issues accordingly.

Project board

We use Github's Project Boards to keep our sprints organized. At the sprint planning, we make sure that the issues contained in the board represent the work that the team agreed to. This way we can focus on what needs to be done and be aware of what decisions are being made. Because we label the issues, we can easily run multiple concurrent branches of development, if needed. By making priorities clear, it's simple to understand when user stories should be delivered and when to call for visual reviews.