How to define a process and SLAs for unpredictable dynamic requirements after project closure?



  • 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?



  • 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.


Log in to reply
 

Suggested Topics

  • 2
  • 2
  • 2
  • 2
  • 2
  • 2
  • 2
  • 2