Project closed, it was managed using Scrum (3 weeks sprints). Now after closing the project, dedicated project members are assigned to another projects. However we want to maintain a Service Level Agreement (SLA) with support, testing and development teams to resolve incident, fix bugs and add new features as it comes and needed in the future.

  1. Entry point is always the user who may create incident if he face an issue or need new function in the tool.
  2. Support team have skills to fix issues if it's NOT related to the tool design/code. This is easy to agree on SLA according to incident priority.
  3. If the incident related to design/code issue or related to new function to be implemented, support team need to create bug/story to development team.
  4. Product team prioritize the bug/story and agree with development team on the estimated effort (hrs) needed.
  5. Development team pick up bugs/stories upon:
    a. Priority of bugs/stories
    b. Available shared resources
    c. Estimated efforts
  6. After implementation and testing, bug fixes/feature deployed to pre-production environment where product owner along with the user can test (UAT).
  7. If successfully passed the UAT, new release deployed to the production environment.

All steps can be measured and develop a SLA for them except step #5 where I can't find a way to define SLA for it because it has 3 dynamic factors and there's no fixed time-boxed sprint. It should be very dynamic and responsive to unpredictable bugs/features coming with time.

What's the best practice to better define this process, measure it and define SLA for it?

  • 3
    Isn't that by definition operations and not project management? – MCW Dec 18 '19 at 13:46
  • 1
    Due to the nondeterministic nature of finding the root causes and proper remedies of bugs, it's likely that a SLA in that area can only focus on effort, not on results, i.e. you can ensure a given amount of developer time is available to analyze bugs, but you can't in general know how long it will take to identify the cause of any given bug. – Hans-Martin Mosner Dec 18 '19 at 13:50
  • Maybe you should look at the downtime cost by the type of an issue? And then try to suggest an appropriate SLA, dedicated persons, plans of resolution (except of fix itself) and the time it is feasible to do. – Andrii H Dec 18 '19 at 19:16
  • @MarkC.Wallace the process itself is more about product management and will run in operation, but I need to design and agree on process before project closure. – Rami Sedhom Dec 19 '19 at 8:10
  • @RamiSedhom An SLA needs to be an operating agreement. Even if it's got legal teeth, approaching it as an immutable set of "thou shalt" statements, rather than as a living policy document that provides working agreements for how services will be provided, will set you up for failure. Don't do that! – Todd A. Jacobs Dec 19 '19 at 16:47

Simply putting, you can't.

What is a Service Level Agreement?

A Service Level Agreement, as the name says, is an agreement stating how a (already existing) service is going to be provided.

SLAs are useful to set the minimum acceptable service levels against specific metrics or Service Level Objectives, such as response time (how long users will have to wait till their reported problems are acknowledged) or service restoration (how long does a failed service will take to be restored).

If a new functionality is required, then it's not a service change, it's a product change.

If a bug on an approved code deployed to production is found, it's not a service change, it's a product change.

Notice that if a bug causes a service failure (such as server downtime), the SLA would be the contract saying how long will it take to bring the service back up, either by fixing the bug or applying any available workaround. In this case the SLO would be server uptime, not bugfix.

And what would be the process to follow up on product changes?

Similar to the process done during the project creation. You'll have a backlog that should be prioritised according to the business needs and available capacity, and then new features will be delivered whenever possible - but not attained to an SLA.



Whether you're dealing with a project or ongoing operations, a service level agreement should focus on time boxing anticipated activities. Fully-knowable activities can have clear time-box boundaries, while others will simply specify cycle times or communication intervals for longer-lived or unanticipated issues.

Focus on Measurable Outcomes Like Response Times or Escalation Paths

However we want to maintain a Service Level Agreement (SLA) with support, testing and development teams to resolve incident, fix bugs and add new features as it comes and needed in the future.

You're making a fundamental mistake in regards to what an SLA actually is when you conflate service delivery with product development. Pragmatically speaking, an SLA is an attempt to manage risk through an operating agreement for the provision of services. An SLA generally defines an explicit time box for responses or escalations, rather than guaranteeing resolutions within a specific time frame.

Consider the following diagram from PMI:

PMI: modified risk quadrants

Successful Service Level Management is generally based on addressing known-knowns like uptime guarantees, or response times for responding to (but not necessarily resolving) unknown-unkowns. This is almost unavoidable, since offering "guarantees" for open-ended or unknowable risks is simply asking for trouble.

A Minimalist Example

From an agile perspective, the simplest thing that could possibly work is to identify how quickly the development or support team can respond to or review new work. For example, broad coverage of your support/development list might look like this once it's boiled down to a few key essentials:

  1. Issues related to uptime guarantees or mission-critical bugs:
    • Will be acknowledged within 1 hour.
    • Will be triaged within 4 hours.
    • Can be escalated if unresolved after 24 hours.
  2. All other issues:
    • Will be acknowledged within 5 business days.
    • Will be accepted or declined within 30 days.
    • Can be tracked on the company's support or development backlog.

These are things that can be measured, and will help the organization budget and schedule to meet the terms of the agreement. You can make it as complex or as burdensome as you want, but a simple starting point that can be improved over time is better than a long document in legalese that is unlikely to be implemented effectively.

In short, target a desirable outcome, make some assumptions about the resources you'll need to meet those targets, and then get all the stakeholders (including support and development staff!) to agree to the operating agreement as a living document that can be updated as organizational realities make themselves felt.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.