Further to the point made by @mbuhot, I’d go so far to say that if the support team and the delivery team don’t understand why features are being prioritised above bugs, you have a product management / ownership problem, not an SLA problem. It can be perfectly valid to priorities features over bug fixes in certain circumstances (e.g. minor annoyance bugs vs major value add feature), but everyone involved should really understand the trade-offs being made. The product owner / manager owns those trade-offs and should be communicating them.
As far as SLAs go, it is quite straightforward to implement them in an agile mode, but, for reasons I’ll cover below, it only really makes sense for external SLAs with customers. Suppose you have 1 week sprints, you could structure your SLAs as follows:
- Critical / Blocker defects -> Kill sprint, fix defects ASAP, get back onto normal backlog work next sprint.
- Major defects -> ensure SLA allows you up to 2 weeks to resolve. Put defect at top of backlog for next sprint. Worst case it gets reported just after a sprint starts and it takes just under 2 sprints to deliver a fix.
- Minor defects -> ensure SLA makes no commitments for fixes. Support provides workaround or “hug” to the customer, defect gets prioritised along with any other feature or marked as WONTFIX. These usually fall off the list unless enough customers complain about them (or you are trying to upsell to the customer and you need to be particularly nice to them).
It’s good practice, in my view, to allow around 20% of the delivery team capacity for triaging / workaround / emergency fixes so you may not have to kill a sprint to handle a critical / blocker issue and you can handle “business as usual” escalations from support. If it isn’t needed you just pull the next feature off the top of the backlog into the sprint.
Back to SLAs between support and development… Support and development are part of the overall system of converting capital and manpower into value. Other parts of the system include strategy, sales, account managers, marketing, finance etc. To do “agile” nicely you need all these functions talking together to prioritise work correctly.
Is the company strategy to become regarded as the best quality provider in the industry, or is the strategy to ship features fast in a new market land grab? Are account managers losing renewals because of defects? Are sales losing deals because of defects? Or are there just a handful of cranky users across thousands of customers that make a lot of unwarranted noise? Are sales pursuing an upsell opportunity in an unhappy customer where a little bit of love would go a long way? Do marketing have a big “feature-release” event planned and paid for resulting in a hard deadline for a new feature? Are the cranky users in customers that are aligned with the overall business strategy, or “legacy” customers? Does dealing with defects result in extra resource requirements in support? These are whole of business questions. Once you have answers to these it becomes pretty straightforward to prioritise.
You are honestly better off getting clarity across the business on what’s important rather than imposing SLAs on your colleagues.
EDIT: Finished last sentence after NBN drop-out lost it (Aussies will understand…)