Introduction
This section is used to describe the Change Management procedures within <GX> Software.
Jira is used to register and track all issues, Bugs and Change requests. Within Jira two projects are defined:
- The Maintenance Backlog is the primary project used for market feedback, registration of new issues and tracking progress on engineering,
- The Product Backlog is uses by Product Management for managing the long term Product Roadmap. Note: the product backlog is currently only available for <GX> employees.
All issues (both Bugs as well as Change requests) have to be reported in The Maintenance Backlog. Although both types of issues are registered in the same Jira project, the change management procedure is different for these two types of issues.
How to register an issue?
Issues have to be registered here in Jira. Everyone can enter new issues. Issues arising within Solutions Units should be entered by the Architect involved. Please choose carefully the type of issue you're creating. The Jira-master will review each issue and set the correct issue-type if necessary, but setting it correctly straight away will make the process more efficient. An overview of available issue types and their definitions can be found here. When registering an Issue you will be prompted for a priority. Please refer to these definitions to determine the correct priority. This will also be reviewed by the Jira Master. Only PS architects may create Blockers or Criticals in JIRA.
Important: If there is no properly documented JIRA issue, there is no issue!
What happens after you register an issue?
- After you register an issue in Jira it wil be moved through the Jira workflow as explained below.
- First the Jira-master will review it as soon as possible. The goal is to to review all new issues within 1 workday.
- As soon as the Jira master starts reviewing the issue it will get the status 'Open'
- If the issue is complete and correct it will get the status 'Accepted', if the issues is not complete and correct it will get the status 'Rejected / Need more info' and will be assigned to the reporter. The reporter can then respond to the comments placed by the Jira master and either 'close' the issue or 're-open' it. If an issue is re-opened it will be evaluated again by the Jira master.
BEWARE:
- Accepted does not mean it will be resolved immediately, it merely means it will be included in the priority process!
- If your issue is 'rejected' you have the opportunity to provide additional info and re-open the issue. Rejected is NOT a definite state.
- Issues that have been on status 'Rejected' for more than 1 month will be automatically closed, so please follow up on your issues on time!
The priority Process
There is a different priority process for Bugs/Improvements and Change Requests. The main difference is the fact that Bugs are included in the weekly maintenance process whereas change requests have to be reviewed and prioritized by Product Management. Both procedures are described below.
The Maintenance Priority Process
- Every week on Thursday at 15:00h the Maintenance Board has a meeting to prioritize all Bugs and Improvements with status 'Accepted' or 'Re-prioritise'.
- Issues with status 're-prioritise' are issues that have previously been scheduled for a release, but for some reason (e.g. Complexity, Regression-risk, Changed priorities due to Blockers) need to be re-evaluated.
- The Maintenance Board will evaluate all issues based on Priority combined with Customer Due Date, Technical necessity and resource availability. The maintenance board strives to plan ahead approximately 1 week of workload for the maintenance team. Due to the fact that Blockers will always be resolved immediately, this will sometimes not be possible.
- The result of this meeting will be processed into Jira. All issues that have been marked to be resolved will be moved to the 'Candidate for Release' status. If the issue is fully clear and resolution time is known, a fix-version will be assigned to the issue. If there is any uncertainty about resolution times or impact, no fix version will be added yet. An engineer will start working on the issue and as soon as resolution times are predictable a fix version will be added.
- Basically all issues not in status New, Open, Design or Accepted are actively being resolved by Product Development. A fix version will be added as soon as the commitment can be made. The current maintenance product planning can be found here
The Change Request Priority Process
Change requests are handled in a different way then Bugs. Change requests are prioritized by Product Management (Martin van Mierloo / Martijn van Berkum) and not by the maintenance board.
As a principle, Change Requests won't be resolved in the Maintenance process but will be included in the Product Roadmap. This effectively means a change request will take at least 3 months (the next release cycle) to be resolved.
However, it is understood some projects require changes quicker. A change can therefore be prioritized for a maintenance release but only if:
- It would otherwise have to be solved with a high-risk closed core violation
- The project will fail / the client will be lost if we don't resolve the request
- The engineering effort is less then 5 days
- The change doesn't unnecessarily impact other clients' functionality or way-of-work
- The change doesn't conflict with GX' long term product strategy
Change request can reside in the Maintenance back-log for quite some time on the 'Accepted' status. A change request in that state is NOT planned for resolution. A change request that will be resolved in Maintenance will be moved ahead to the 'Candidate for Release' status and a fix-version will be assigned. From there on it will move through the engineering process.
A change request that will be resolved in the Product Roadmap will be moved to the Product Backlog where it will be further spec'd and assigned to a major (9.x) fix version. The current product roadmap can be found here.
Product Managements aims to respond to new change requests within 2 weeks. The response will tell you:
- whether the change will be resolved in maintenance (fix-version assigend),
- or if it will be put on the product roadmap list, and therefore will only be prioritized when the next product roadmap is published (the [roadmap calendar]can be found here),
- or if it is rejected definitely as it conflicts with product strategy (status rejected),
- or if it's not prioritized now, but will be kept for later re-evaluation (accepted but no fix-version).
