Each piece of Feedback (including complaints, crash reports and errors) is treated as an Incident. The process for handling these depends on where we’re at in the development cycle.
Pre-market
In the initial phase of product development (prior to the first release build going to market) modifications can be made without the need to perform the full battery of pre-release acceptance tests.
This means we can adopt a pretty straightforward process:
At the Triage stage, the product owner will manage the assessment of the Incident. Depending on the scope of the reported issue, there may need to be a conversation around how the Incident should be prioritised.
Some reported issues (e.g. a low risk UI edge case that was observed on a single device and cannot be replicated) may be recorded here, but not yet prioritised for a resolution. Much here depends on severity, budget and anticipated scope of the fix.
When an issue is added to the current sprint for resolution, we will look to minimise the risk of regression in future:
- The relevant Requirement(s) will be reviewed to see if they contain any ambiguity. If they do, they will be updated to improve clarity.
- Code will be improved/refactored as a patch, to resolve the issue.
- Additional tests will be added where feasible, to catch future regressions.
Once the PR has been reviewed and merged, the standard release process can proceed, and the changes validated in the next release build, to confirm that the issue has been resolved.
Since the patch goes through the standard Pull Request review process, we’ll have full traceability of the reported issue and the steps taken to resolve it.
Post-market
At the point of delivery, this process is likely to change, particularly if a client’s in-house team is taking over the product maintenance or DevOps responsibilities.
That can sometimes mean a new feedback process and workflow, or a fork of our approach.