Overview

This article outlines Nezasa’s regular software development and delivery processes.

Nezasa uses agile software development principles to continuously improve its Software as a Service (SaaS) platform. This approach increases development velocity and transparency while minimising costs and risks.

Development cycles are defined by Quarterly Product Roadmaps and Bi-weekly Development Sprints.

Quarterly Product Roadmap

The Product Roadmap provides medium to long term planning for platform development.

Nezasa plans two quarters in advance. While the first quarter contains more detailed planning and significant deliverables, known as “Epics,” the second quarter focuses mostly on strategic ideas.

Quarterly Roadmap schedule:

1. Planning Freeze: One month before the start of a new quarter (28-Feb, 31-May, 31-Aug, 30-Nov), the roadmap for the next quarter is finalised.
2. Start Roadmap Execution: At the beginning of each quarter, execution of the roadmap begins. The scope for these three months is fixed and can only be changed for exceptional reasons.
3. End Roadmap Execution: At the end of each quarter, the execution ends, and implementation of the next quarter’s roadmap items begins.

Bi-weekly Development Sprints 

Development Sprints are short-time roadmap executions using agile principles. Nezasa plans bi-weekly sprints.

Sprint Schedule:

1. Planning Freeze: The week before the sprint starts, the planning is finalised (usually on Thursdays).
2. Sprint Start: Each sprint begins on a Thursday morning and runs for two weeks. The scope is fixed unless a critical bug is reported. Less critical bugs will be addressed in subsequent sprints.
3. Sprint End: Each sprint concludes on the Wednesday afternoon of the second week.
4. Business Acceptance: One week after delivery, the work is considered accepted by the client unless otherwise agreed (only applicable for custom developments).

Regression Testing by Customers

Nezasa’s Staging environment is optimised for internal testing and release processes and does not come with any SLA. Key activities during the second week of the sprint include:

• Thursday (7 PM CET): The production database is cloned to the Staging database, which results in the loss of any Staging content not present in Production. The Staging environment is unavailable during this period (close to 7 hours).

• Monday and Tuesday: Release candidates are deployed until the release is stable and all relevant tests are performed.

• Tuesday: Automated tests are executed.

Testing Recommendations for Customers:

• Do not test before Tuesday.
• Staging is less stable than Production and even more so during release days, leading to potential interruptions.
• Avoid immediately reporting bugs or instabilities. Re-check later or wait until after the next release candidate. The release version can be found in the application header.

• If reporting issues from Staging, always mention the release version and specify that the issue was found in Staging, not Production.

Note that the opportunity for regression testing is not intended to report minor issues or improvements. Nezasa welcomes such feedback but requests re-testing in Production or Staging after the official release. Only severe issues will be addressed during release days through standard reporting channels. Some severe issues may need to be addressed in a follow-up release.

Business Acceptance

Nezasa will notify customers when a custom development item is delivered to the production environment. Customers have one week after delivery notification to report any defects or issues. The delivery will be considered accepted if any feedback is received within this period.