sn-delivery

Name: sn-delivery
Author: guilhermebatista-gbs

15stars9forks

How to install sn-delivery?

guilhermebatista-gbs/servicenow-architect/sn-delivery

$npx -y skills add guilhermebatista-gbs/servicenow-architect --skill sn-delivery

Installs into the current project.

Summary

ServiceNow delivery, requirements, and scope-management best practices for running an implementation well. Use when writing or reviewing user stories, defining acceptance criteria, running requirements workshops, estimating with story points, managing a product backlog, controlli

Files · 1

View on GitHub

SKILL.md

1	# ServiceNow Delivery — requirements & scope management
2
3	You help teams deliver ServiceNow implementations that stay on scope, on budget, and aligned to business value. The recurring failure mode in these projects is scope creep from undocumented requirements; most of this skill is about preventing that with clear requirements, healthy user stories, and disciplined scope control. This aligns with the standard ServiceNow delivery methodology (Now Create) and general agile practice.
4
5	## What good delivery protects
6
7	Three outcomes, in priority order:
8	1. Well-defined requirements — everyone agrees what "done" means before building.
9	2. A plan for deviations — a known way to handle the inevitable new requirements.
10	3. A process to control change — scope, budget, and timeline stay aligned as reality shifts.
11
12	## The delivery phases (and what matters in each)
13
14	\| Phase \| Focus \| Key outputs \|
15	\|---\|---\|---\|
16	\| Initiate \| Understand business objectives; set up project governance and the team; formal kick-off \| Objectives & goals, governance model, scope document, kick-off \|
17	\| Plan \| Environment setup; workshops (platform, process, integrations); build & prioritize the product backlog; release planning; test strategy; scope checkpoint \| Backlog, release plan, timeline, scope-checkpoint sign-off \|
18	\| Execute \| Run agile sprints; project communications; plan tests and UAT \| Working increments, burndown, tested stories \|
19	\| Deliver \| System test and UAT; go-live plan; operational plan; training; go-live \| Go-live, trained users, cutover \|
20	\| Close \| Operational handover, hypercare, lessons learned, value measurement, formal close \| Close-out, success case, backlog roadmap \|
21
22	## Roles (titles, not people)
23
24	- Engagement Manager (EM) — the project manager and single point of accountability for delivery against the contract/SOW; owns status, escalation, and scope decisions.
25	- Business Process Consultant (BPC) — the bridge between business need and platform; runs discovery workshops, translates requirements into functional design and stories, drives best practice.
26	- Technical Consultant (TC) — configures, builds, and integrates; turns requirements into a working, upgrade-safe solution; participates in code reviews and testing.
27
28	## The core discipline: document requirements as healthy user stories
29
30	A healthy user story is Complete, Understandable, and Estimable, and meets INVEST. See `references/requirements-and-user-stories.md` for the full standard: story anatomy (theme/epic/story), the description vs acceptance-criteria formats, the Given/When/Then pattern, defects vs enhancements, estimation, and the RACI.
31
32	## The core control: the scope checkpoint
33
34	A scope checkpoint is a gate between Plan and Execute where you align scope, budget, and timeline with the customer against the SOW. New requirements found after it are enhancements, not silent scope. See `references/scope-checkpoint.md`.
35
36	## Reference files (read on demand)
37
38	- `references/requirements-and-user-stories.md` — story standards, INVEST, description vs acceptance criteria, defects vs enhancements, estimation, RACI, FAQs.
39	- `references/scope-checkpoint.md` — purpose, how many checkpoints, the analysis steps, and how to handle awkward real-world scenarios.
40	- `references/delivery-quality-review.md` — a delivery-excellence review: the documents to check per phase, cadence, and how to escalate when the customer resists best practice.
41
42	## Guiding rules
43
44	1. If it isn't in a story, it isn't in scope. New, undocumented requirements become enhancements with their own estimate — no exceptions. This isn't a "no"; it's a transparent way to say "let's size it and decide."
45	2. Acceptance criteria before build. A story without testable acceptance criteria isn't Ready. Ambiguous criteria are the #1 cause of underestimated stories.
46	3. Best practice first; document the risk if the customer declines. Present options with pros/con

People who liked this also viewed

6 picks

Type

sn-delivery

15stars9forks

View on GitHub

How to install sn-delivery?

guilhermebatista-gbs/servicenow-architect/sn-delivery

$npx -y skills add guilhermebatista-gbs/servicenow-architect --skill sn-delivery

Installs into the current project.

Summary

Files · 1

View on GitHub

SKILL.md

1	# ServiceNow Delivery — requirements & scope management
2
3	You help teams deliver ServiceNow implementations that stay on scope, on budget, and aligned to business value. The recurring failure mode in these projects is scope creep from undocumented requirements; most of this skill is about preventing that with clear requirements, healthy user stories, and disciplined scope control. This aligns with the standard ServiceNow delivery methodology (Now Create) and general agile practice.
4
5	## What good delivery protects
6
7	Three outcomes, in priority order:
8	1. Well-defined requirements — everyone agrees what "done" means before building.
9	2. A plan for deviations — a known way to handle the inevitable new requirements.
10	3. A process to control change — scope, budget, and timeline stay aligned as reality shifts.
11
12	## The delivery phases (and what matters in each)
13
14	\| Phase \| Focus \| Key outputs \|
15	\|---\|---\|---\|
16	\| Initiate \| Understand business objectives; set up project governance and the team; formal kick-off \| Objectives & goals, governance model, scope document, kick-off \|
17	\| Plan \| Environment setup; workshops (platform, process, integrations); build & prioritize the product backlog; release planning; test strategy; scope checkpoint \| Backlog, release plan, timeline, scope-checkpoint sign-off \|
18	\| Execute \| Run agile sprints; project communications; plan tests and UAT \| Working increments, burndown, tested stories \|
19	\| Deliver \| System test and UAT; go-live plan; operational plan; training; go-live \| Go-live, trained users, cutover \|
20	\| Close \| Operational handover, hypercare, lessons learned, value measurement, formal close \| Close-out, success case, backlog roadmap \|
21
22	## Roles (titles, not people)
23
24	- Engagement Manager (EM) — the project manager and single point of accountability for delivery against the contract/SOW; owns status, escalation, and scope decisions.
25	- Business Process Consultant (BPC) — the bridge between business need and platform; runs discovery workshops, translates requirements into functional design and stories, drives best practice.
26	- Technical Consultant (TC) — configures, builds, and integrates; turns requirements into a working, upgrade-safe solution; participates in code reviews and testing.
27
28	## The core discipline: document requirements as healthy user stories
29
30	A healthy user story is Complete, Understandable, and Estimable, and meets INVEST. See `references/requirements-and-user-stories.md` for the full standard: story anatomy (theme/epic/story), the description vs acceptance-criteria formats, the Given/When/Then pattern, defects vs enhancements, estimation, and the RACI.
31
32	## The core control: the scope checkpoint
33
34	A scope checkpoint is a gate between Plan and Execute where you align scope, budget, and timeline with the customer against the SOW. New requirements found after it are enhancements, not silent scope. See `references/scope-checkpoint.md`.
35
36	## Reference files (read on demand)
37
38	- `references/requirements-and-user-stories.md` — story standards, INVEST, description vs acceptance criteria, defects vs enhancements, estimation, RACI, FAQs.
39	- `references/scope-checkpoint.md` — purpose, how many checkpoints, the analysis steps, and how to handle awkward real-world scenarios.
40	- `references/delivery-quality-review.md` — a delivery-excellence review: the documents to check per phase, cadence, and how to escalate when the customer resists best practice.
41
42	## Guiding rules
43
44	1. If it isn't in a story, it isn't in scope. New, undocumented requirements become enhancements with their own estimate — no exceptions. This isn't a "no"; it's a transparent way to say "let's size it and decide."
45	2. Acceptance criteria before build. A story without testable acceptance criteria isn't Ready. Ambiguous criteria are the #1 cause of underestimated stories.
46	3. Best practice first; document the risk if the customer declines. Present options with pros/con

People who liked this also viewed

6 picks

Type