Standard Operating Procedure Document
Goal: When considering tickets for Engineering Sprints the Product and Engineering Team must be able to quickly vet the ticket for:
Priority
Required Design Work
Time to completion
Impact to Customer
Standardizing our ticketing format allows for the most information to be provided from the outset while minimizing the amount of follow up questions in the process. For now, there are two main types of ticketing that will be accepted as submissions.
Ticket Types
Bug Tickets
Bug tickets are reports of a clear and obvious flaw in the software that cause it to produce an unexpected result, or behave in unintended ways.
Bug Tickets should consist of as many of the following fields as possible:
Impacted Customer: What facility or facilities and customer(s) are being impacted by this bug?
Impacted Product: Which offering is being impacted? (Asset Tracking, Hand Hygiene, etc.)
Date First Noticed: Please provide a rough timeline of when this began or when it was first reported.
Observed Behavior: Describe the issue in as much detail as possible. If the customer reported the issue, include a description of their report as it was related to you.
Expected Results: When everything is working exactly as intended, what do we expect this process to look like?
Steps to Reproduce: In order for us to address the issue as quickly as possible, we need to be able to recreate. Please help us do that by describing how to recreate this issue in our own environment. (Remember to attach any materials that may be helpful).
Troubleshooting Attempted So Far: If you’ve already taken any steps to remediate give a brief description of them here.
Work Around/Stop Gap: Is there an interim solution for this while it gets worked into the sprint?
Impact of Issue: What are the immediate and long term effects of this issue going unresolved?
Desired Timeline: Has there been any communication of timeline to or from the customer? (This will not guarantee that it can be completed in that timeline, but it will help to organize incoming tickets.)
Feature Enhancements
Feature Enhancement tickets are requests for any product change or upgrade that increases the capabilities of the software and the user value beyond the previous state.
A Feature Enhancement Request should include:
Current State: What is our current process for the task in question? If we do not currently have a feature or process in place, it can also be noted here.
Requested Enhancement: What improvements or enhancements to the current state are you requesting?
Impact Statement: Why is this change needed at this time? (Ex. scalability/efficiency, revenue, customer retention, contractual promise, quality control, etc.)
**When detailing the impact statement, make sure you’re also communicating the impact to you. Are you spending tons of manual hours on this weekly? Is it causing you to work exhaustive hours? are you the only one carrying this load? Something that may not be urgent to a customer can still be an urgent request for you. Let us know.
Origin of Request: Any additional details that might be relevant about the user that made this request.