1

Like many in this forum, I am working in an enterprise organisation that subscribes largely to the ITIL model of service management.

A discrete team that provide guidance and sign-off for service acceptance.

A set of criteria used for service acceptance testing to ensure that an IT service meets its functionality and quality requirements and that the service provider is ready to operate the new service when it has been deployed

This is a wrapper that envelopes the entirety of the product (normally near the end of the delivery) that dictates such things as

  • Documented processes (who is getting called out on a Sunday if it goes down etc)
  • SLA's
  • OLA's
  • BAU team

This is a common constraint when attempting to deliver a Product within the Scrum Framework using the User Story pattern. It is closely linked to the idea that, in a user story, it is often hard to articulate NFR's.

Most Service Acceptance Checklist's can run to 100-150 line items. Is there a best practice for how to incorporate this list into the backlog of a Scrum Team?

Any answer that involves disbanding the ITIL Service Team is considered off topic for this question since Organisational Change is not possible at this time.

Improve this question
5
  • Can you cite some examples? "Has to be able to serve X concurrent users on resources Y" seems to be a thing that can be put into a user story, but "who gets called on Sunday if it's down" is policy, not requirement.
    – nvoigt
    Aug 16, 2018 at 15:58
  • Service Acceptance is almost all policy adherence and auditing.
    – Venture2099
    Aug 16, 2018 at 16:07
  • Well, the fact that next year, John will be the emergency contact for Sundays is impossible to put into a user story, because it's not even a requirement. It's not something the product needs to be able to do, whether it's functional or non-functional. And assuming that John is not part of the Scrum Team but some kind of DevOps/Operational guy, how would the Scrum Team even know that or be able to influence it? I can see one user story to be "As an operator I want to have an operations manual" or something similar, but policy is just not possible and that has nothing to do with Scrum.
    – nvoigt
    Aug 16, 2018 at 16:13
  • What I meant by nothing to do with Scrum is that I don't think you could have a milestone in a waterfall project that is "John will be called on Sundays next year when it goes live". So however you did this before Scrum... why not keep that process or adapt it?
    – nvoigt
    Aug 16, 2018 at 16:18
  • The process in waterfall is "complete the service acceptance checklist". But that typically spans a much longer period than a Scrum timebox. If you write a single user story it would be around 4 Sprints long if not longer. I have a way of breaking it down to make it work but I wanted to see if someone else had solved it.
    – Venture2099
    Aug 16, 2018 at 22:31

1 Answer 1

Reset to default
2

A user-story is a description of a Requirement.

I think what you are concerned with is about describing a Specification.

Specifications are not rendered as user-stories; they can (and should) be rendered as acceptance criteria attached to the story.

For example, if a ORR checklist says things like: - Have all new logging functions had a archiving and alerting strategy implemented? - Has performance load on a production-like system been carried out?

You can render these as acceptance criteria attached to your story.

Given we are implementing a new logging function When the log file exceeds one gigabyte Then the oldest 200 MB is archived to ...[destination]... and alert SMS messages are sent to ...[numbers or group]... and email alert messages are sent to ....[addresses]...

Given we must handle processing of 10,000 transactions per minute When the system is running at this load Then transaction processing time does not exceed 100 ms and CPU load on a production-like server does not exceed 50% and RAM consumption does not exceed 8 GB

etc...

These are testable acceptance criteria - you don't need your checklist because the testing out turns prove the quality has been built-in.

If you have standard things that need to apply to all stories then they can be created as a standards document or as a standard set of acceptance criteria.

This is analysis - it has nothing to do with whether you are running agile or waterfall, it has to do with the quality of the analysis.

The reason why we run checklists (The ambulance at the bottom of the cliff) is precisely because we don't do enough analysis before we implement things. Agile/devOps thinking makes this better not worse.

If you want to build your understanding in this area I recommend you read up on Behavioural-Driven-Development and the concept of shifting-left.

Also if you haven't got it already, get your hands on a copy of the DevOps handbook by Gene Kim & Co. This is a book that is worth reading a few times.

Cheers

Improve this answer
2
  • Tash, whilst I appreciate it, your post has a lot of assumptions in it that are incorrect. We already use AC and are quite fluent in BDD. This is an ITIL question not a DevOps question. Most enterprise teams are not running the service they build.
    – Venture2099
    Aug 18, 2018 at 7:06
  • If you move your sign off criteria into the acceptance criteria for the story, then your sign off stops being the ambulance at the bottom of the cliff and actually contributes to building in quality. NFRs by definition are not referred to in stories, because they are specification, not requirement. For as long as we try to build NFS (specification) into Stories (Requirements) then we are going to struggle. It doesn't change whether or not enterprise teams support the item, it is better if they do, because then there is a natural bias towards them wanting to do this, but not a pre-requisite
    – user33299
    Aug 19, 2018 at 5:21

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge that you have read and understand our privacy policy and code of conduct.

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