We are now more tightly project managing our work load, but still need to maintain responsiveness to unplanned issues as they arise.
The goal of this document is to define a simple process specific to our team and projects, where important new issues are identified quickly, and can have time allocated to them without delay.
By documenting this process in a short doc, we can ensure that no team member will be uncertain about what to do when a new issue arrives, and who is responsible.
We want to avoid:
- Urgent issues sitting unattended without anyone working on them.
- Developers getting bothered by non-sprint work.
- Multiple team members “piling on” to the same issue, when one or two would be enough.
- Unnecessary expansion of sprint scope.
- Unnecessary overtime work.
- The tech lead being a bottleneck and a single point of failure in the process.
- Developers assigned to an urgent issue but blocked.
- Stakeholders not knowing what’s going on.
- Unreasonable expectations from stakeholders
- Failing to use multiple time zones to our advantage.
Types of new work
- Bug reports (of varying severity and impact)
- Support requests
- Feature requests
- Collaboration opportunities
Sources of new work
- Product Team (BA)
- Internal testing by developers and QA
- Daedalus team
-
Technical Services Desk (IOHK support for end-users)
- TSD field many support requests and provide workarounds for bugs.
- Most often, support tickets come from Daedalus users.
- Exchanges
- Stake pool operators
- Application developers
- Company executives
- GitHub Issues
How do I recognise an urgent issue?
Examples of urgent issues. These type of things are the subject of this document.
- Any problems reported by exchanges that could result in disabling Ada withdrawals, or delisting of Ada (e.g. severe performance degradation).
- Key functions of the wallet don’t work for a significant number of users (e.g. can’t make a payment).
- Key functions of the wallet produce an incorrect result (e.g. incorrect balance).
- Issues identified as important by company executives
- An issue which genuinely prevents other development teams who use our software from completing their work.
How do I recognise a non-urgent issue
Examples of things which aren’t urgent, and for which the normal process applies for including them in a sprint.
- There is a useable workaround for the affected user(s).
- It’s about something we never intend to support.
- It’s a normal feature request.
Resolution process
-
Triage
- Identify the problem that the user is having.
- Look for indications that this is an urgent issue.
- If definitely urgent, commence Work. If unsure, escalate to slack channel.
-
Work
- Ensure that there is an ADP jira ticket, in the current sprint, and it’s assigned. Notify the PM.
- Identify the steps required to reproduce the issue, blah, blah, the normal thing.
- When solving an urgent issue, the goal is not necessarily to make a perfect solution, or even to make any code fix at all. The goal is to make the user happy enough that the issue is no longer urgent.
- Don’t get stuck.
- Be very cautious when requesting or handling commercially sensitive information.
- Update your tickets more often than you would normally.
-
Resolution
- If there is a useable workaround, the issue becomes non-urgent and can be handled as normal.
- If there is a bug fix, make a new release when possible.
- A development build could be provided to affected users, but this is a bad habit to get into.
Who is responsible
- Triage phase - Probably a “bug sherrif” rotation system as used by Daedalus team would be suitable for us.
- Work - The important thing is that urgent issues are assigned to someone not no-one. The PM or tech lead can assign the work. If nobody steps up, then the bug sherrif will need to assign themselves.
- Resolution - tech lead.