🚀 Building a Cloud Center of Excellence: The Launch Stage 🔧📦
So far in our Building a Cloud Center of Excellence series, we’ve covered the groundwork:
- In The Pathfinder Journey , we set the stage for the transformation ahead, breaking down the roadmap to cloud maturity.
- In The Envision Stage , we defined the why behind the CCoE, clarifying the vision, building a common frame of reference, and securing leadership buy-in.
- In The Align Stage , we tuned the instruments and synchronized the team—establishing clear accountabilities, shaping enablers, and aligning delivery around a common tempo.
We have envisioned where we want to go. We have aligned our stakeholders, mapped out the big rocks, and secured leadership buy-in. Now it’s time to light the engines.
The post-it notes are on the wall. The backlog is taking shape. The team is ready.
Welcome to the Launch Stage. Where we stop planning and start building.
🧭 What Is the Launch Stage?
The Launch Stage is where our CCoE moves from thinking to doing. It’s the moment where alignment turns into execution. Plans on paper become real work.
This is also when the Pathfinder team hands over the baton. Some members take on permanent roles within the CCoE. Others have completed their mission—their journey ends here.
Like any agile journey, the goal isn’t to deliver everything at once. It’s to build momentum. To get moving, deliver value, and create a rhythm that can be improved with every sprint.
Think of the Launch Stage like choosing the right instruments for an orchestra. Before we can play, we need to select the tools, arrange the sheet music, and agree on the tempo.
🔮 Run a Pre-mortem
Before diving into sprint planning, pause.
The Launch Stage is about momentum, but building speed without awareness is dangerous. A pre-mortem helps the CCoE team to see and avoid the potholes down the road.
In a pre-mortem workshop, gather the CCoE team and key stakeholders. Ask a simple but powerful question:
👉 “Imagine it’s six months from now and this initiative has failed. What went wrong?”
This exercise surfaces risks that might otherwise stay hidden.
💬 Common patterns often emerge:
- “Nobody really owns the work.”
- “We are doing this next to our day jobs.”
- “We don’t have the right access or permissions.”
- “We are blocked because we’re waiting on other teams.”
Document every risk, group related concerns, and make them visible to everyone involved.
The goal isn’t to solve every problem today. It’s to create awareness, so the CCoE team can navigate obstacles—not be surprised by them mid-sprint.
If alignment provides a shared direction, the pre-mortem provides a shared realism. Both are essential before moving into execution.
🧱 Define Workshop: Shape Epics and Features
This is where the CCoE backlog is born. The first step is to translate strategic goals into Epics and Features. This forms the foundation of the CCoE backlog and becomes the engine behind the first sprints.
Each Epic should connect back to the outcomes aligned on earlier: platform enablement, security guardrails, developer experience, cost management, and more. This isn’t just about building technical components; it’s about enabling the organization to move faster, safer, and smarter in the cloud.
If you’re unfamiliar with how Epics, Features, and Stories fit together, check out this guide on Azure DevOps work items for a quick overview.
🎯 Pro tips:
- Initial collaboration works best in person. Run a physical brown paper session to map out Epics and Features together.
- Once aligned, digitize the results into a tool like Miro, Azure DevOps Delivery Plans, or whichever tool fits best.
- Keep business outcomes visible. Every Epic should tie back to a clear why.
- Avoid over-engineering at this stage. Detailed refinement will happen later during the next workshops.
This phase is about creating structure without losing momentum—and setting the scaffolding that the CCoE’s future delivery will stand on.
✂️ Refinement Workshop: User Stories and Tasks
Once Epics and Features are in place, it’s time to make the work executable.
The Refinement Workshop is where these higher-level ideas are broken down into User Stories / Product Backlog Items and in some cases, Tasks. This makes the backlog tangible.
There are two types of User Stories in the backlog.
Some are owned and executed by the CCoE team. These focus on enabling capabilities under one of the three pillars of the CCoE: Governance, Brokerage, and Community.
Others are delivered by the Platform Team. These are more technical in nature and focus on implementing cloud infrastructure or automation. Often, they flow directly from CCoE stories. For example, a governance policy defined by the CCoE might lead to a backlog item for the Platform Team to enforce that policy through Azure Policy or RBAC.
To accommodate this, ensure that both teams have their own sprint backlogs with a common main backlog.
A good User Story is small, testable, and independent. Each should express a clear value or need. Often doing so in the form of a persona and goal improves it’s clarity.
🛠 Example:
- Feature: “Cloud Cost Awareness Campaign”
- User Story: “As a product owner, I want clear guidance on cloud budgeting so I can plan responsibly and avoid cost overruns.”
- Task: “Create and publish a cost management playbook on the internal wiki”
Don’t overthink the perfect format. Focus on clarity and outcomes. If something is too large or vague, split it or flag it for more discussion.
This is also where backlog gaps and dependencies tend to show up. That’s a good thing—it allows the team to adjust and reprioritize before sprinting starts.
By the end of this session, the CCoE Team should have a well-structured backlog, shaped in collaboration with the people who will deliver it.
🗂️ Planning Workshop: From Backlog to Sprint
In the Planning Workshop, the CCoE team reviews the backlog, evaluates priorities, and selects the stories that will form the initial sprint. This step is not just about choosing work, it’s about setting a delivery rhythm and making the first iteration feel achievable and focused.
Prioritization is typically based on impact and dependencies:
- What delivers the most value fastest?
- What unlocks progress for others?
- What’s required before anything else can start?
Once priorities are clear, the team groups stories into a first sprint and, optionally, outlines rough plans for Sprint 2 or 3. And just to reiterate: the goal is not to have everything perfect, but to have enough clarity to start.
💡 Example planning pattern:
- Sprint 1: Governance — Define and communicate guiding principles, landing zone policies, and baseline guardrails.
- Sprint 2: Brokerage — Set up request processes for platform services (e.g. Landing Zone provisioning, cost estimates, access requests).
- Sprint 3+: Community — Launch onboarding sessions, document knowledge in a central hub, and establish feedback channels with early adopters.
Quick wins help prove progress. Foundational items set the stage for sustainable delivery.
It’s also worth defining a basic sprint cadence here: weekly, bi-weekly, 3–5 stories per sprint, and a short feedback loop between sprints. Planning creates commitment but also flexibility. What matters most is starting with structure, not perfection.
🚦 Kick-off CCoE Sprint 1: Definition of Done
The Sprint Kick-off marks the transition from planning to execution. The CCoE Team agrees on scope, confirms responsibilities, and sets expectations. But one thing matters more than any board or burndown chart:
👉 A shared understanding of what “done” means.
The Definition of Done (DoD) is the quality gate. It ensures consistency across the team, and it prevents work from being “almost done” but never delivered.
🧾 A typical CCoE Definition of Done includes:
- Outcome documented and shared with relevant stakeholders
- An architectural decision record (ADR) created (if applicable)
- Reviewed by at least one peer (e.g. a policy, playbook, or workshop format)
- Supporting artefact published (template, document, portal entry)
- Any required communications or training assets created
- Follow-up actions or technical backlog items identified (if handoff is needed)
This isn’t about perfection. It’s about closing the loop and setting a quality bar that everyone can see.
Kick off Sprint 1 with a short ceremony. Keep it focused: scope, ownership, blockers. Use it to reinforce the DoD and to give the work visibility.
Don’t expect it to be flawless—and it doesn’t have to be. Focus on building momentum, delivering value, and reinforcing the operating model of the CCoE in practice.
Wrapping Up
The Launch Stage turns strategy into motion, transforming vision, alignment, and backlog preparation into actual delivery. By surfacing risks early, shaping work around meaningful outcomes, and kicking off the first sprint with clarity and intent, organizations can build real momentum for their Cloud Center of Excellence.
Stay tuned for the final stage in our Cloud Center of Excellence series, where we’ll shift focus toward expanding CCoE capabilities and accelerating impact during the Pathfinder: Scale stage.
If you found this post useful, be sure to explore the reference materials that inspired it:
- Microsoft Cloud Adoption Framework
- Microsoft Cloud Adoption Framework - Cloud center of excellence (CCoE) functions
- Team Topologies - Key Concepts
- Set Up Your Organization for Cloud Adoption Success - Gartner
- Execute Your Cloud Strategy With a Cloud Center of Excellence - Gartner
- Building a CCOE to transform the entire enterprise
- The CCoE phases
- How to Build a Successful CCoE: A Step-by-Step Guide
- How to build a cloud center of excellence
- Kwartiermakersgilde
- Quartermaster - Britannica
- Quartermaster - Wikipedia
Thank you so much for taking the time to read this post. If you enjoyed it or learned something new, don’t hesitate to check out my other posts . If you have questions or feedback, feel free to reach out via LinkedIn . Until next time, happy automating! ✨