MKG logo
Login

What happens to my report? Part 4: Handling



Thousands of users work with our software daily. Generally, this occurs without many issues. However, occasionally, unexpected or undesirable results from certain actions can create obstacles in your work. In such cases, you can report your issue to us. How do we then handle this report? In four parts, we guide you through the journey your report takes within MKG. In part 4: handling a report.


Sprint

After the refinement (evaluation) of the reports by the Development department, the reports are handled according to the scrum model. The sprint is the most important part.

Hoogenboom Valves

In each 4-week sprint, work is done on a new version that is then delivered.

Reports can be about anything, such as a request for a new feature, a new functionality, an error message, or a proposal for improvement. Determining which reports are addressed in a sprint is based on various factors, such as:

- the expected effort
- the number of users who reported it
- the number of users who will benefit from it
- the available capacity in the development department
- the risk of the adjustment
- how well it fits into the strategic planning and roadmap determined by the product team/management team


During the sprint planning, the development team decides which reports will be handled in a 4-week sprint. These reports are placed in the sprint backlog (in our case in the TOPdesk program) as the definitive work list. Other reports go to the product backlog and are picked up in subsequent sprints as much as possible. During the sprint, a brief daily meeting takes place, the scrum, where each developer indicates what they delivered the previous day, what will be done today, and what obstacles they are encountering during the sprint. At the end of the sprint, the review demonstrates the version to be delivered to the stakeholders (the management, team leaders, and other interested parties) to receive feedback on the solutions developed. Then, a retrospective takes place in which the development team discusses collaboration and possible improvements in the work process.


Release/delivery of a version

All adjustments in a version are thoroughly tested by MKG's test team. Standard tests are also conducted with each version: a regression test that includes all crucial processes, a technical test (for update processes), and a performance test. After approval of these tests, all adjustments are described and published as release notes in My MKG. The new version is then first sent to a select group of Beta customers to see how it works in practice. Normally, a general release follows a week later for all customers. An update is recognized by the version number, for example, from version 005.057.xxx to version 005.058.xxx. When your report is delivered in a version, you receive feedback about it through that report.


Patches

It may occur that despite all tests, errors still arise in the software. These are followed up in patches apart from the fixed sprint planning to get the solutions to the end-user faster. A patch is recognized by the increase of the last number in the version number, for example, from version 005.057.006 to patch 005.057.007. In general, we advise our users to always work with the latest available version of MKG to benefit from the most recent improvements in the software.

This was the last part of the series 'What happens to my report?'

 
notificationerror messagecapacityversion no.functionality