Skip to content

SORMAS Sprint Process

Maté Strysewske edited this page Mar 10, 2023 · 3 revisions

Introduction

The core development of SORMAS follows SCRUM as closely as possible. Development work is done in sprints that are usually three weeks long. These sprints start with a Planning where the development team decides, based on a list of priorities given to them, which issues are going to be implemented in the upcoming sprint, and it ends with a Review together with the main stakeholders, and usually the release of a new version.

In order to ensure that new releases are properly tested and there is enough time to take care of necessary bugfixes, there is a feature freeze ahead of the release. Normally, the Review that ends the sprint is done on a Tuesday, and the feature freeze takes place on the Thursday before.

Sprint Backlogs

The issues that have been picked up for development in the current sprint are organised in two GitHub projects:

These backlogs are divided into different categories that describe the status of the issues that are assigned to them:

  • Backlog: Issues that are planned to be picked up during the current sprint, but for which development has not yet started. The sorting from top to bottom reflects the priority given by the Product Owner at the time of the Planning.
  • In Progress: Issues that have been assigned to a contributor and for which development work has started.
  • Waiting: Issues for which work has been started but which have been put on hold, e.g. because action or feedback by an external contributor is required.
  • Review: Issues that have been resolved and are awaiting review by another contributor. In general, it is required that issues undergo both a functional as well as a code review by another core developer before they are merged into the development branch.
  • Testing: Issues that have been resolved, reviewed, merged and successfully tested (i.e. they satisfy the Definition of Done), and are now waiting to be re-tested/verified by QA on a central test instance. Issues in this lane are supposed to be closed, to carry appropriate labels and the milestone of the version to which they merged.
  • Done: Issues that have been closed and most often have been verified by QA is possible/feasible.