Every Amazon Connect project — a greenfield build or a migration off a legacy platform — tends to need the same core set of work, even though the detail differs wildly by organisation. Rather than invent a structure, this backlog is built directly on AWS's own Prescriptive Guidance for Amazon Connect migrations[1], which recommends running three parallel workstreams, each with its own five-phase delivery rhythm: discovery, design, build, test, deploy, and post go-live support.[2][3][4]
- Technical Foundation — infrastructure, Connect configuration, networking, security, DevOps/IaC. High cost of change, so design carefully up front.
- User Journeys — the actual contact flows, IVR/agentic experiences, and routing logic. Low cost of change — build fast, iterate often.
- Operational — governance, the operating model, training, and service introduction. The non-technical work that decides whether people actually adopt the new platform.
This article organises the backlog as Epics (one per phase, per workstream) containing Stories you can paste straight into Jira, Azure DevOps, or Linear. Story points are illustrative (relative sizing, not a promise) — recalibrate against your own team's velocity.
Epics in this backlog
Epic 1: Discovery & Alignment
ACP-1
Discovery & Alignment
Align project scope to business outcomes before any design work starts. Per AWS guidance, this is "the first formal activity of the project" and validates earlier plans and estimates against stakeholder input.[4]
| Key | Story | Workstream | Pts |
|---|---|---|---|
| ACP-101 | As the project sponsor, I want a documented vision statement and guiding principles so decisions throughout the project have a consistent reference point | Ops | 3 |
| ACP-102 | As a business analyst, I want to run as-is mapping workshops to understand current contact centre systems, capabilities, and pain points | Tech | 5 |
| ACP-103 | As a solutions architect, I want a to-be design and gap assessment so the project scope and MVP/MLP are clearly bounded | Tech | 8 |
| ACP-104 | As the project team, I want a gap closure roadmap outlining how we build and deploy the future-state contact centre | Tech | 5 |
| ACP-105 | As stakeholders, we want to agree desired business outcomes, their priority, and success criteria before design begins | Ops | 3 |
| ACP-106 | As the project team, I want a high-level solution design to accelerate low-level design in later phases | Tech | 5 |
| ACP-107 | As the sponsor, I want timelines and implementation costs validated against the agreed scope | Ops | 3 |
| ACP-108 | As the project team, I want existing user journey flows and designs gathered and handed to the contact flow build team | Journey | 3 |
| ACP-109 | As stakeholders, I want a collaborative workshop to develop a user journey framework in a visual tool (contact flow designer, Visio, or draw.io) | Journey | 5 |
| ACP-110 | As the project manager, I want recurring, transparent governance cadences (steering, risk/issue log) established from day one | Ops | 3 |
Workshop attendees (per AWS guidance): project managers, business/solutions/technical/security architects, infrastructure platform owners, business analysts, and the service line owner/operator.[2][3]
Epic 2: Technical Design
ACP-2
Technical Design
Produce design documents covering Connect configuration, networking, and security. AWS recommends at least three distinct sections (often separate documents) since each has different specialist reviewers.[2]
| Key | Story | Workstream | Pts |
|---|---|---|---|
| ACP-201 | As a solutions architect, I want to design the Amazon Connect instance configuration (routing profiles, queues, security profiles, hours of operation) | Tech | 8 |
| ACP-202 | As a network architect, I want to design the networking architecture (VPC, PSTN/SIP connectivity, telephony provider integration) | Tech | 8 |
| ACP-203 | As a security architect, I want to produce a security design covering IAM, data residency, encryption, and compliance requirements, reviewed by the security & compliance team | Tech | 8 |
| ACP-204 | As the project team, I want to decide our multi-account strategy (minimum: development, test, production AWS accounts) | Tech | 5 |
| ACP-205 | As a platform owner, I want third-party and backend system integrations (CRM, WFM, identity provider, knowledge base) identified and designed | Tech | 8 |
| ACP-206 | As the data team, I want the data model and data pipeline designed (e.g. streaming Connect data to a data lake/warehouse) | Tech | 5 |
| ACP-207 | As the DevOps lead, I want our IaC toolchain decided (AWS CodePipeline/CodeBuild or equivalent) and scoped into the project plan | Tech | 5 |
| ACP-208 | As architects and security/compliance stakeholders, we want formal design sign-off before build begins | Tech | 2 |
Epic 3: User Journey Design
ACP-3
User Journey Design
Design is often lightweight here — if you use the contact flow designer itself, the journey is self-documenting.[3] This is the low-cost-of-change, iterate-fast workstream.
| Key | Story | Workstream | Pts |
|---|---|---|---|
| ACP-301 | As a business analyst, I want each in-scope service line's call reasons mapped and prioritised for the MLP (minimum lovable product) | Journey | 5 |
| ACP-302 | As a conversation designer, I want to design the welcome/greeting, main menu, and routing logic for each in-scope journey | Journey | 5 |
| ACP-303 | As a conversation designer, I want prompt placeholders flagged with a named owner for anything not yet confirmed (exact wording, audio files) | Journey | 3 |
| ACP-304 | As a designer, I want the identification & verification (ID&V) journey designed and agreed with security/compliance | Journey | 8 |
| ACP-305 | As a designer, I want no-input/no-match and error-handling behaviour designed for every recognition point | Journey | 5 |
| ACP-306 | As a designer, I want queue/hold experience designed (hold music, position-in-queue messaging, callback offer, estimated wait time) | Journey | 5 |
| ACP-307 | As an AI/conversation designer, I want the agentic/self-service AI experience scoped (if in-scope) — intents, tools, guardrails, escalation criteria | Journey | 8 |
| ACP-308 | As a designer, I want each journey's design self-documented in the contact flow designer (or an equivalent change-controlled design doc) | Journey | 3 |
| ACP-309 | As the service line owner, I want to review and sign off the designed journeys before build starts | Journey | 2 |
Epic 4: Operating Model Definition
ACP-4
Operating Model Definition
Defines who uses and manages the solution and how — not a runbook, but who is accountable for what.[4] Typically finalised in the second half of the project, once the solution design and journeys are settled, but stakeholders should be lined up early.
| Key | Story | Workstream | Pts |
|---|---|---|---|
| ACP-401 | As the project manager, I want a RASCI matrix defining which team is Responsible, Accountable, Supported, Consulted, and Informed for each operational activity | Ops | 5 |
| ACP-402 | As operations, I want a process-flow swimlane for out-of-hours support (who gets paged, escalation, ticket logging) | Ops | 5 |
| ACP-403 | As operations, I want a process flow for emergency/business-continuity announcements (who decides, what data triggers it, who actuates it) | Ops | 3 |
| ACP-404 | As the BAU support team, I want the new platform incorporated into our existing support model and ticketing categories before go-live | Ops | 5 |
| ACP-405 | As the service introduction (SI) team, I want to be engaged early and included on the design distribution list, not brought in at the end | Ops | 2 |
| ACP-406 | As the SI team, I want go-live entry criteria and checklists agreed (UAT results, training completion, no clashing change-freeze events) | Ops | 3 |
| ACP-407 | As stakeholders, we want to select the appropriate AWS support plan ahead of go-live | Ops | 2 |
| ACP-408 | As all teams, we want to sign off the operating model as a formal gate before the platform moves to production | Ops | 2 |
Epic 5: Technical Build
ACP-5
Technical Build
AWS explicitly warns against a manual build process, even if it's faster to start with — it raises instability and bug risk as the build is promoted to test and production.[2]
| Key | Story | Workstream | Pts |
|---|---|---|---|
| ACP-501 | As a cloud engineer, I want development, test, and production AWS accounts provisioned under a landing zone / AWS Organizations structure | Tech | 8 |
| ACP-502 | As the DevOps lead, I want IaC pipelines set up (AWS CodePipeline/CodeBuild or equivalent) to promote Connect configuration across environments | Tech | 8 |
| ACP-503 | As a developer, I want the Amazon Connect instance, security profiles, routing profiles, and queues built via IaC/API, not console clicks | Tech | 8 |
| ACP-504 | As a developer, I want phone numbers (DID/toll-free) claimed in a non-production environment for build and test use | Tech | 3 |
| ACP-505 | As a developer, I want the identity provider / SSO integration built and tested for agent and admin login | Tech | 8 |
| ACP-506 | As a developer, I want CRM/CTI and backend system integrations (Lambda functions, API Gateway) built per the integration design | Tech | 13 |
| ACP-507 | As a developer, I want call recording storage, retention policy, and access controls configured in S3 | Tech | 5 |
| ACP-508 | As a data engineer, I want the data pipeline built to stream Contact Trace Records (CTRs) and Agent Events to the data lake/warehouse | Tech | 8 |
| ACP-509 | As a DevOps engineer, I want a DevOps operational runbook created covering deployment, rollback, and incident response | Tech | 5 |
| ACP-510 | As a security engineer, I want monitoring and alerting (CloudWatch, security monitoring tool integration) configured for the platform | Tech | 5 |
Epic 6: Contact Flow / Journey Build
ACP-6
Contact Flow / Journey Build
Build can start in a dev environment before every AWS account exists, then export/promote flows as JSON once test and production Connect instances are ready.[3]
| Key | Story | Workstream | Pts |
|---|---|---|---|
| ACP-601 | As a Connect developer, I want the welcome/greeting and main menu contact flow built in the development instance | Journey | 5 |
| ACP-602 | As a Connect developer, I want each priority call-reason journey built end-to-end (recognition, routing, queue, transfer/resolution) | Journey | 8 |
| ACP-603 | As a Connect developer, I want the ID&V module built as a reusable flow module and wired into journeys that require it | Journey | 8 |
| ACP-604 | As a Connect developer, I want no-input/no-match retries and fallback/escalation paths built for every recognition point | Journey | 5 |
| ACP-605 | As a Connect developer, I want queue flows built with hold music, position-in-queue messaging, and callback offer where designed | Journey | 5 |
| ACP-606 | As a Connect/AI developer, I want the agentic AI experience (if in scope) built — AI Agent node, tool integrations, knowledge base, guardrails | Journey | 13 |
| ACP-607 | As a Connect developer, I want all prompts and audio recorded/generated, referenced by ID, and reviewed against the design | Journey | 8 |
| ACP-608 | As a Connect developer, I want contact flows exported as JSON and version-controlled alongside the IaC pipeline | Journey | 3 |
| ACP-609 | As a Connect developer, I want routing profiles and queues wired to each built journey and validated in the dev instance | Journey | 5 |
Epic 7: Test (Unit, Integration, Functional, UAT)
ACP-7
Test
AWS defines three sequential technical test subphases (unit, integration, product/functional) plus UAT as a distinct, business-owned gate that must pass before deploy.[2][3]
| Key | Story | Workstream | Pts |
|---|---|---|---|
| ACP-701 | As a developer, I want unit tests covering individual infrastructure components against design specifications | Tech | 5 |
| ACP-702 | As a developer, I want integration tests covering boundary systems (identity provider, CRM, telephony carrier) | Tech | 8 |
| ACP-703 | As the functional test team, I want end-to-end product tests covering each user journey, including that agent events log correctly and recordings land in the right S3 bucket | Tech | 8 |
| ACP-704 | As the functional test team, I want iterative functional testing of each contact flow as it's built in Connect, within the agile sprint cadence | Journey | 8 |
| ACP-705 | As an eval/quality engineer, I want an adversarial and edge-case test set built for any AI/agentic journeys (ambiguous input, no-match, escalation triggers) | Journey | 8 |
| ACP-706 | As business users, I want to run User Acceptance Testing (UAT) scripts against the built journeys only after functional tests pass | Journey | 8 |
| ACP-707 | As the project team, I want all UAT issues triaged and either fixed or formally accepted by stakeholders before go-live | Journey | 5 |
| ACP-708 | As the project team, I want security & compliance to confirm the platform is ready for live traffic from their perspective | Tech | 3 |
Epic 8: Training & Service Introduction
ACP-8
Training & Service Introduction
"Technology can work perfectly, but if users don't know how to answer calls and perform their daily tasks, the migration will be considered a failure."[4] AWS recommends a train-the-trainer approach using the organisation's own training staff.
| Key | Story | Workstream | Pts |
|---|---|---|---|
| ACP-801 | As a project SME, I want user manuals, admin console guides, and screen guides produced as source material for trainers | Ops | 8 |
| ACP-802 | As the training team, I want a train-the-trainer session delivered to in-house trainers using project SME material | Ops | 5 |
| ACP-803 | As an agent, I want hands-on training on the new platform (login, handling calls/chats, using screen pops) before go-live | Ops | 8 |
| ACP-804 | As a supervisor, I want training on real-time dashboards, reporting, and agent management in Connect | Ops | 5 |
| ACP-805 | As a system administrator/product owner, I want formal, instructor-led Amazon Connect product training to troubleshoot and configure effectively | Ops | 5 |
| ACP-806 | As the SI team, I want to confirm no clashing change-freeze or other go-live events are scheduled for the cutover date | Ops | 2 |
| ACP-807 | As the SI team, I want sign-off that users have completed training and operations teams are ready, as a go-live entry criterion | Ops | 2 |
Epic 9: Deploy & Go-Live Cutover
ACP-9
Deploy & Go-Live Cutover
Drawn directly from AWS's published pre-go-live and go-live-day checklists.[5]
| Key | Story | Workstream | Pts |
|---|---|---|---|
| ACP-901 | As the project team, I want to verify the release has passed UAT and all remaining issues are accepted by stakeholders | Tech | 2 |
| ACP-902 | As the telephony lead, I want the number cutover planned — TFNS repoint readiness or a number-porting ticket filed well ahead of go-live | Tech | 5 |
| ACP-903 | As the project team, I want the code base deployed to the production environment (via its own change request, ahead of the go-live CR) | Tech | 5 |
| ACP-904 | As the project team, I want in-scope service lines to run UAT scripts against a temporary production phone number (pipe-clean testing) | Journey | 5 |
| ACP-905 | As the project manager, I want a go-live change request submitted and approved by the Change Approval Board (CAB) | Ops | 2 |
| ACP-906 | As the project team, I want agent and user credentials uploaded to the production instance ahead of cutover | Tech | 3 |
| ACP-907 | As the cutover team, I want a conference bridge open for stakeholders for status updates, kept open until cutover (or rollback) completes | Ops | 1 |
| ACP-908 | As the cutover team, I want the public number cutover (TFNS repoint / porting) executed at the approved time | Tech | 3 |
| ACP-909 | As the cutover team, I want real-time Connect dashboard metrics monitored at go-live (calls answered, abandonment, AHT, queue depth) | Ops | 2 |
| ACP-910 | As the project team, I want a tested rollback plan (swap the number back to the legacy service) ready to execute if needed | Tech | 3 |
Epic 10: Post Go-Live Support (PGLS)
ACP-10
Post Go-Live Support
The project team stays engaged with BAU support and end-users for the first few weeks after go-live.[2][3]
| Key | Story | Workstream | Pts |
|---|---|---|---|
| ACP-1001 | As the PGLS team, I want to be present and visible (on-site or remote help desk) during the first days of go-live | Ops | 3 |
| ACP-1002 | As the PGLS team, I want to work alongside the BAU support team on any issues raised in the first weeks | Ops | 5 |
| ACP-1003 | As the project team, I want to help end-users get started on the new platform through floor-walking and quick-reference support | Ops | 5 |
| ACP-1004 | As the project team, I want support documentation improved based on real post-go-live feedback | Ops | 3 |
| ACP-1005 | As the project team, I want contact flows refined based on real customer and agent feedback once live | Journey | 5 |
| ACP-1006 | As operations, I want a formal handover from the project team to BAU support once PGLS exit criteria are met | Ops | 2 |
| ACP-1007 | As the project team, I want a lessons-learned retrospective and a backlog of post-launch optimisations captured for future sprints | Ops | 3 |
How to Use This Backlog
- Run three parallel workstreams, not one sequential list. AWS's guidance is explicit that technical foundation, user journeys, and operational work should run as autonomous, parallel workstreams with tracked dependencies between them — not as one waterfall backlog.[6]
- Start with Sprint 0, then an MLP sprint. Sprint 0 covers kick-off, discovery, planning, and design (Epics 1–4). The first delivery sprint should target a minimum lovable product — a straightforward journey for a small group of agents — before iterating toward the full target state.[7]
- Treat the three workstreams differently. Technical foundation and operational work are high-cost-to-change — invest in up-front design. User journeys are low-cost-to-change — build fast, test often, expect the final journey to differ from the first draft.[2][3]
- Re-size everything. The story points here are illustrative placeholders for relative sizing, not a committed estimate — recalibrate against your own team's velocity and the actual scope of your project.
- Strip what doesn't apply. A greenfield build has less "as-is mapping" than a legacy migration; a voice-only project can drop the agentic-AI stories; a single-country deployment can simplify the telephony stories.
- Keep the go-live checklist (Epic 9) as a literal checklist, not just stories — it's the one AWS publishes as a direct pre-flight list, and it's worth keeping that discipline.[5]
The one-line summary: technical foundation and operations are built once, carefully; user journeys are built many times, quickly. A backlog that treats all three the same way is the most common planning mistake on Amazon Connect projects.
Want the people side of this same backlog — who actually owns each of these epics? Read the companion post: Amazon Connect Project Roles & Responsibilities. And if you're designing the user-journey epics (3 and 6) visually, the free IVR Design Tool is purpose-built for exactly that.
Sources
This backlog is structured directly on AWS's own published migration guidance. Content was summarised and rephrased for compliance; see each source for full detail. This is independent guidance and is not affiliated with or endorsed by AWS.
- AWS Prescriptive Guidance — Strategy for migrating to Amazon Connect: Overview
- AWS Prescriptive Guidance — Technical foundation workstream
- AWS Prescriptive Guidance — User journeys workstream
- AWS Prescriptive Guidance — Operational workstream
- AWS Prescriptive Guidance — Migration checklists (pre-go-live and go-live day)
- AWS Prescriptive Guidance — Project phases and workstreams
- AWS Prescriptive Guidance — Agile methods to accelerate delivery and innovation