Unplanned changes comes from various sources:
Penetration test remediation
InfoSec and AppSec may identify vulnerabilities that need to be patched
Browser incompatibilities and breaks
Sales engineering and support
All of these sources represent critical business needs and often disrupt our plan. Having a plan in place for how and when to interrupt the plan is important. There are three key steps to this: identify & log, prioritize and escalate, and resolve
We first need to identify and log the reason for the unplanned change. Identifying and logging means understanding what work needs to be done and recording it. Let's take an an example from Customer Solutions to describe this.
Every day our customers reach out to our Customer Solution Specialists for support using our products. Often times, they reach out to tell us about a defect. The Customer Solutions Specialist confirms the defect through replication and logs the issue into our issue management system describing the issue in detail including an estimation of it's impact to the business.
All unplanned changes should be logged similarly. However, not all unplanned change is a defect. So, we can take the Customer Solutions example above and modify it slightly to fit a wider audience:
After we've identified and logged the needed change we need to prioritize it. We should prioritize a change by categorizing it into one of four categories:
Critical = Needs to be addressed immediately (hot fix)
High = Needs to be addressed soon
Medium = Can be addressed through Product/Project management scheduling
Low = Does not need to be addressed with any specific timeline
The way we determine what category a change should fall into is by assessing it's importance. We do this by looking at it's impact to the business. Impact should be evaluated by considering the frequency, scope, and severity of the affect of the defect or absence of change.
How often the issue affects our users or how often users will be impacted by the absence of the change. When thinking about frequency you should consider how often a user will observe the given defect or how often they will benefit from the change.
How wide is the surface area of the defect or change. You should consider what extent of the product is affected by the defect.
How significantly does the change effect the user or workflow. We should ask how impactful the change will be to our users experience. When thinking about severity consider the following levels:
Severity 1 - The feature is broken and there is no workaround
Severity 2 - The feature’s most common usage path is broken but there is a workaround
Severity 3 - One of the feature’s less common usage paths is broken and there is a more common workaround
For Sales Engineering and Support:
Severity 1 - Change is needed to close a deal with a significant price tag or with a significant new customer
Severity 2 - Change will unblock a significant opportunity that is in stuck in the pipeline
Severity 3 - Change would make a material difference to a substantial prospect that is considering us
If during prioritization we determine that a change needs to happen immediately we need to escalate it immediately otherwise we should escalate it during regular prioritization (see below). Department heads may escalate product changes if they feel a change needs to occur.
If your dealing with a defect, the first thing you should do is send the issue to Customer Solutions. They can work with the customer to find a work-around and will replicate the issue as a first step toward resolving it. Otherwise, if you're not dealing with a defect, the first thing you should do is bring it to your manager. Your manager can then evaluate how you've prioritized the change. If they feel it needs to be further escalated they should then notify product engineering.
To escalate a change post a message in the #escalation Slack channel. Project management and engineering are listening to this channel and can respond quickly during business hours. If it's after hours and you need an immediate response use the #s_o_s channel.
All changes will be reflected in the issue management system and the reporter who logged the request for change will be notified anytime the issue is updated including when the issue is shipped to production. In the event you need to communicate with the person working on an issue, each issue identifies the person who the issue is assigned to in the "assigned to" field. When issues are shipped to production issues are marked "In Release". In cases where the change was related to a customer, the Customer Solutions Manager responsible for the change or relationship will follow up with the customer to let them know that the issue has been resolved.
Department heads have the option to attended a weekly prioritization meeting led by Project Management. Department heads from Product, Engineering, and Project Management will be in regular attendance. However, any department heads that a change in the next development iteration should attend to make sure the change gets planned. To join this meeting speak to the Project Management Team.