What is the release policy of the RetailVista ERP software by NedFox?

This document describes how NedFox handles modifications in RetailVista ERP, future updates, bug fixes, etc. RetailVista POS is not covered by this documentation, a separate release document QA 367 is available for that. Pilot/test processes are also not covered by this release policy. 

RetailVista is offered as a hosted product, where each retail organization runs in a separate instance that can be updated individually. This allows for updating instances separately, at a separate pace.

Tasks

In order to streamline the development process, NedFox registers all modification requests as tasks in eSocrates. The status of all tasks can be tracked by both customers and resellers in eSocrates (for customers through the support website).

Throughout the year, new tasks are added to eSocrates based on various customer contacts. These tasks are assigned an application, classification 1 and 2, priority, impact, task type (error report, feature request, etc.), and some other less important attributes. The customer associated with each task is also recorded. In some cases, an estimated time indication is also recorded for how long the realization of a task is expected to take.

Backlog

The backlog is a selection of tasks from which sprints will be filled. The backlog contains a limited selection of all available tasks in eSocrates.

At regular intervals, certain tasks are added to the backlog and assigned an estimated time indication (if not already present) and priority/execution order. The tasks that qualify for this are generally determined from a commercial standpoint.

In addition, tasks of the type 'Error message' or 'Malfunction' are always taken over in the backlog and given a high priority.

The tasks with the highest priority in the backlog are provided with a test script and, if necessary, a storyline describing exactly how the adjustment should look and work.

Please note: No rights can be derived from the tasks in the backlog! If tasks are really crucial, the costs for implementation will be charged to the customer, the task in the backlog will be given a very high priority and will therefore be scheduled in the next sprint. Only then can it be guaranteed that a task will be part of the next release.

Sprint

Sprints are used for actual software modifications. Each sprint lasts 2 weeks and at the start of each sprint, the number of available hours in the next 2 weeks is calculated. With this information, the tasks with the highest priority are taken from the backlog, until the number of available hours in the sprint is reached.

Sometimes the amount of work in a sprint is less than expected. Initially, overtime is used to try to complete the sprint anyway. If that is not possible, the scope of the sprint is reduced. It may happen that some tasks that were planned in the sprint are not completed. As a rule, these tasks are automatically moved with the highest priority to the next sprint.

It also happens sometimes that the impact of a task turns out to be too extensive and a task is removed from a sprint. At that moment, the aim is to handle the task in the next sprint.

In the last sprint before a final release, it may happen that certain tasks will not make it to the release and will be part of the subsequent release.

Within each sprint, a development and acceptance test is performed.

Testing after the sprint

After each sprint, test environments are updated upon request, if available. This allows resellers and customers to become aware of the changes made and, if desired, perform test work.

After installing this update, NedFox conducts a functional test.

Any rejections from the functional test or the reseller test will be addressed in the sprint following the new sprint that has already started. Assuming a 2-week sprint, it may take approximately 4 weeks for these rejections to be resolved and made available.

Rollout of interim release

In special cases, it is possible to deploy a release to a production environment after a sprint. This release will have lower quality than a final release because integration tests have not yet taken place.

Translations from English to, for example, Dutch may also be missing in these releases. This will be addressed in the final release.

If a customer chooses an interim release, the consequence is that the customer is effectively obligated to install the subsequent interim releases until the final release is deployed. See also the 'bug fixes' section.

Rollout of final release

Currently, NedFox has 2 final releases of RetailVista per year. Typically, a release is done in October and February. A release consists of a series of sprints that have been completed consecutively, forming the ultimate update.

In order to perform a final release, all tasks that are part of this release have been functionally tested by NedFox.

Also, integration tests are carried out on important components to check if the coherence between the different modules still functions correctly. All new data in this release has been translated from English to Dutch. Because of these points, a final release has a higher quality than an interim release.

After the last sprint for the October and February release, it is up to the reseller (if applicable) to give the green light per instance to roll out the update. Without approval, an instance will not be updated. After receiving the approval, NedFox will agree on a date with the reseller. The approval per version will eventually become part of eSocrates.

The placement of the updates is carried out by NedFox in accordance with the SLA (maintenance after 10:00 PM) and until Wednesday evening at the latest. After Wednesday evening, no more updates will be placed, in order to reasonably guarantee a quiet weekend. When placing an update, an announcement will be sent at least 24 hours in advance. Depending on the SPOC (Single Point Of Contact) settings, this message will go directly to the relevant customers or to the reseller. In the latter case, the reseller is responsible for correct communication with its customers.

Release documentation

A release document is created for each official release. This is a QA in eSocrates that can also be read from RetailVista. It lists almost all the tasks that are part of the release. It may happen that some tasks are difficult to describe because they solve a very technical problem and are not described in the release documentation.

No release documentation is created for releases after any random sprint. This only takes place for the biannual updates.

Bug fixes on test environments

Identified errors in the software on test environments are planned and resolved in the next sprint that is yet to begin. In contrast to errors in production environments, a bugfix is not made and deployed for an error in a test environment.

Bugfixes on production environments (interim sprint release)

Identified errors in the software on production environments, for which no workaround exists and which are truly disruptive, are resolved through bugfixes. The aim is to resolve these within a few working days, depending somewhat on the complexity of the bug.

If it is possible to work around the bug, it will be resolved in the next official release.

A prerequisite for resolving a bug is that the customer is working with the latest sprint release. Bugs can only be fixed in the latest sprint. If the customer is not using the latest sprint release, they will need to update first. The deployment of an update can take place every week, but is scheduled for Monday morning.

Bugfixes on production environments (final release)

Identified errors in the software on production environments, for which no workaround exists and which are truly disruptive, are resolved through bugfixes. The aim is to resolve these within a few working days, depending somewhat on the complexity of the bug.

If it is possible to work around the bug, it will be resolved in the next official release.

A prerequisite for resolving a bug is that the customer is working with the latest official release version. Bugs can only be fixed in the latest official release. If the customer is not using the latest release, they will need to update first. The deployment of an update can take place every week, but is scheduled for Monday morning.