Run a SaaS Release Command Centre

Build an Azure Boards command centre and steering brief for a SaaS release.

Introduction

30 Second Summary

A plan can look healthy when every team shares only its own piece of the story. Trouble surfaces when the full picture arrives too late for a safe decision.

In this project, you will lead a fictional global workforce-management SaaS release toward a defensible conditional launch decision. Your command centre in Azure Boards feeds a human-reviewed steering brief created with Claude Free and PowerPoint for the web.

What You'll Build

You present a six-slide steering brief that connects a conditional UK pilot recommendation to the risks, release gates, owners, and actions visible in your command-centre dashboard.

By the end of this project, you'll have:

A cross-functional command centre that lets you trace each visible risk to its release outcome.
A conditional go/no-go decision backed by DORA metrics, operational controls, and named owners.
A reviewed six-slide steering brief that communicates the recommendation through evidence plus a measured Claude productivity scorecard.
Secret Mission: Replan the release after a four-week vendor delay while keeping the dashboard and steering brief consistent.

Are there any prerequisites?

You need existing Azure Boards, Claude Free, PowerPoint for the web, and OneDrive access. The exercise requires permission to create a private Azure DevOps project but no coding experience.

Before We Start

This first checkpoint helps you define the management outcome you want to demonstrate before the simulation begins. You will connect controlled release decision-making to the Software Operations Manager role.

Set Up the Command Centre

Your release simulation now has a clear management outcome. The next risk is fragmented setup across several accounts.

A private sandbox gives you room to practise senior decisions without exposing employer data. You will prepare each workspace before release evidence starts arriving.

In this step, get ready to:

Prepare Microsoft Edge plus a private Azure DevOps Services project using the Scrum process.
Configure a privacy-safe Claude Free workspace for fictional scenario data.
Verify the presentation path through Microsoft OneDrive plus Microsoft PowerPoint for the web.

Prepare the browser and Azure DevOps sandbox

Microsoft Edge gives you one browser for the entire simulation. Azure Boards provides the private workspace where you will connect release scope to management evidence.

Press Cmd+Space on macOS or the Windows key on Windows to open the operating system search bar.
Type Microsoft Edge into the search bar.
Press Enter to open Microsoft Edge.

✔️ Microsoft Edge opens

Microsoft Edge is ready. Keep the browser open for the remaining setup.

ⓧ Microsoft Edge is unavailable

Use your current browser to install Microsoft Edge from Microsoft's official download page.

Visit the official Microsoft Edge download page.
Choose the download for your operating system.
Complete the Microsoft Edge installation.
Repeat the operating system search to confirm that Microsoft Edge opens.

Microsoft Edge Still Unavailable?

Check that the installer finished before repeating the search. Your device may also require administrator approval for software installation.

Help me resolve the Microsoft Edge installation on my device.

Keep the Sandbox Free

This project stays free when your Azure DevOps organization remains within its included Basic allocation. You do not need any paid feature for this simulation.

Keep the organization within its first five Basic users.
Keep your access level at Basic.
Do not assign Basic + Test Plans.
Do not add paid Azure Pipelines parallel jobs.
Do not enable GitHub Advanced Security.
Keep Azure Artifacts storage at 2 GB or less.

Visit Azure DevOps Services in Microsoft Edge.
Sign in with the account that has Azure Boards access.
Choose an Azure DevOps organization where you have project-creation permission.

The Projects page now anchors the sandbox inside an organization you control.

Select New project.
Enter Global SaaS Release Command Centre as the project name.
Choose Private for the visibility.
Expand Advanced.
Select Scrum as the work item process.
Select Create.

Azure DevOps opens the new private project after creation.

Missing New Project?

Your account needs membership in Project Collection Administrators or the Create new projects permission set to Allow.

Switch to an Azure DevOps organization you own.
Create an organization from the organization selector if you do not own one.
Ask the organization owner to grant the required project-creation permission if needed.

Help me find the project-creation permission I am missing.

Select Boards in the Azure DevOps sidebar.
Select Boards from the expanded menu.
Confirm that the board selector shows Backlog items.

Your private Scrum board is working. It now gives the release simulation a controlled home.

Apply safe Claude Free settings

Claude can create the steering presentation later in the simulation. Its privacy controls help you keep the productivity experiment limited to sanitized fictional facts.

Open a new tab in Microsoft Edge.
Visit Claude Free.
Sign in with your confirmed Claude Free account.
Select your user name.
Select Settings.
Select Privacy.
Turn off Help Improve our AI models.

The privacy toggle now appears off for future chats.

Select Capabilities.
Turn on Code execution and file creation.
Confirm that the capability toggle appears on.

Keep the Workspace Fictional

You are keeping this workspace fictional, so there is no reason to expose sensitive data.

Use only the fictional release scenario in Claude.
Keep confidential business documents out of Claude.
Keep personal data out of Claude.
Keep credentials out of Claude.
Keep source code out of Claude.
Keep real employee information out of Claude.

Verify the presentation path

Microsoft 365 connects the file store to the presentation editor. Verifying that path now prevents account access from interrupting the steering brief later.

Open a new tab in Microsoft Edge.
Visit Microsoft365.com.
Sign in with your confirmed Microsoft 365 account.
Select PowerPoint.
Confirm that PowerPoint for the web opens.
Select the app launcher.
Select OneDrive.
Confirm that OneDrive opens with your signed-in account.

Why Keep Separate Tabs Available?

The simulation moves between release evidence and executive communication. Separate tabs keep each workspace one click away during the management review.

Open another new tab in Microsoft Edge.
Return to Microsoft365.com.
Select PowerPoint to keep it available beside OneDrive.

Before you check, predict whether all four workspaces are ready for the release simulation.

Switch back to the Azure DevOps project tab.
Select Boards in the sidebar.
Select Boards from the expanded menu.
Confirm that the board selector still shows Backlog items.

The Azure Boards check proves that your private Scrum project is accessible.

Switch to the Claude tab.
Confirm that Help Improve our AI models is off.
Confirm that Code execution and file creation is on.
Switch to the OneDrive tab.
Confirm that your signed-in OneDrive files are accessible.
Switch to the PowerPoint tab.
Confirm that PowerPoint for the web remains signed in.

You can now access the private project from Azure Boards. Claude shows the safe privacy state plus the required file capability. OneDrive and PowerPoint remain available in separate tabs.

That is the setup complete. Next, you will turn the private sandbox into a cross-functional release portfolio.

Build the Release Portfolio

The private Scrum sandbox in Azure Boards is ready. You can now turn the fictional release into a portfolio that leadership can govern.

A manager cannot govern architecture or quality when every function keeps a disconnected list. This portfolio connects product scope with operational readiness through one visible hierarchy.

In this step, get ready to:

Create the release Epic with four cross-functional Features.
Organize six Product Backlog Items under the appropriate Features.
Add planning details before moving the highest-value work into active states.

Create the portfolio spine

The Scrum hierarchy moves from an Epic to Features before reaching Product Backlog Items. Each level gives leadership a different view of the same release.

How does the hierarchy work?

An Epic represents the complete release outcome.
A Feature groups work for one management area.
A Product Backlog Item defines a visible outcome that supports its Feature.

Switch back to the Azure Boards tab from earlier.
Select Boards in the left sidebar.
Select Backlogs.
Open the backlog level selector near the top of the page.
Select Epics.
Select New Work Item.
Enter Release 4.2: Global Payroll Expansion as the title.
Press Enter to add the Epic.

You should see the new Epic at the top of the Epics backlog.

Double-click Release 4.2: Global Payroll Expansion to open its work item form.
Choose a future release date in the Target Date field.
Enter Launch compliant payroll integrations through a controlled country pilot. in the Description field.
Save the Epic from the work item form.

Good progress. The release now has a business outcome with a target date.

Select Features from the backlog level selector.
Add Product and Architecture through New Work Item.
Add Quality and Release Automation through New Work Item.
Add Support and Operational Readiness through New Work Item.
Add People and AI Enablement through New Work Item.

You should now see four Features in the backlog.

Select View options above the backlog.
Select Mapping to display the mapping pane.
Drag Product and Architecture onto Release 4.2: Global Payroll Expansion.
Drag Quality and Release Automation onto Release 4.2: Global Payroll Expansion.
Drag Support and Operational Readiness onto Release 4.2: Global Payroll Expansion.
Drag People and AI Enablement onto Release 4.2: Global Payroll Expansion.
Return to View options.
Turn Parents on.

Each Feature should now show Release 4.2: Global Payroll Expansion as its parent.

What does mapping do?

Mapping creates the parent-child links behind the portfolio view. Those links let leadership trace every planned outcome back to the release Epic.

Cannot map the Features?

Confirm that the backlog level is set to Features. The mapping pane should list the Epic as the available parent.

Turn Parents on if the relationship remains hidden after mapping.

Help me fix my Azure Boards Feature-to-Epic mapping.

Add outcomes to each management area

Product Backlog Items turn each management area into work with an observable outcome. The parent links keep product scope and operational readiness connected to the same release.

Select Backlog items from the backlog level selector.
Add Pilot UK and Singapore payroll adapters through New Work Item.
Add Validate the payroll integration architecture through New Work Item.
Add Enforce automated regression and rollback gates through New Work Item.
Add Publish the support runbook and escalation map through New Work Item.
Add Cross-train APAC operations through New Work Item.
Add Pilot AI-assisted release summaries through New Work Item.

You should see six Product Backlog Items in the backlog.

Select View options.
Select Mapping to display the Features.
Drag Pilot UK and Singapore payroll adapters onto Product and Architecture.
Drag Validate the payroll integration architecture onto Product and Architecture.
Drag Enforce automated regression and rollback gates onto Quality and Release Automation.

The product and quality outcomes now have visible owners at the Feature level.

Drag Publish the support runbook and escalation map onto Support and Operational Readiness.
Drag Cross-train APAC operations onto People and AI Enablement.
Drag Pilot AI-assisted release summaries onto People and AI Enablement.
Return to View options.
Turn Parents on.

Every Product Backlog Item should now display its Feature parent. The Features already connect those outcomes to the release Epic.

Is a backlog item under the wrong Feature?

Drag the Product Backlog Item onto the correct Feature in the Mapping pane. Azure Boards updates the parent-child link when you drop it.

Help me correct my Product Backlog Item hierarchy.

Make the initial plan credible

A title alone does not support a release decision. Planning fields show relative effort and value before acceptance evidence defines what completion means.

What do the planning fields show?

Effort captures the relative size of the work.
Business Value ranks one PBI against the other PBIs.
Description states the outcome that the PBI delivers.
Acceptance Criteria states the observable evidence required for completion.

Complete the Effort field on all six PBIs with relative estimates that fit your simulated plan.
Save each PBI after entering its effort estimate.

The six PBIs now carry relative effort estimates for planning conversations.

Write one outcome sentence in the Description field of every PBI.
Save each PBI after completing its description.

Each PBI now explains the management outcome behind its title.

Write one observable completion condition in the Acceptance Criteria field of every PBI.
Save each PBI after completing its acceptance criteria.

Each PBI now has a visible test for whether its outcome is complete.

Use this value order

Validate the payroll integration architecture receives a Business Value of 100.
Enforce automated regression and rollback gates receives a Business Value of 90.
Publish the support runbook and escalation map receives a Business Value of 80.
Pilot UK and Singapore payroll adapters receives a Business Value of 70.
Cross-train APAC operations receives a Business Value of 60.
Pilot AI-assisted release summaries receives a Business Value of 50.

Apply the scorecard by entering the listed value in the Business Value field of each PBI.
Save each PBI after entering its Business Value.

The architecture review and release controls now lead the value ranking.

Select Boards in the left sidebar.
Confirm that the board selector shows Backlog items.
Move Validate the payroll integration architecture from New to Approved.
Move Enforce automated regression and rollback gates from New to Approved.
Move Publish the support runbook and escalation map from New to Approved.
Move Pilot UK and Singapore payroll adapters from New to Committed.

The board now presents a credible accepted plan. Three high-value controls are Approved while the country pilot is Committed.

Before you verify the portfolio, do you expect every outcome to trace back to one release Epic?

Select Backlogs under Boards.
Select Epics from the backlog level selector.
Confirm that Release 4.2: Global Payroll Expansion appears in the backlog.
Select Features from the backlog level selector.
Confirm that all four Features show the release Epic as their parent.
Select Backlog items from the backlog level selector.
Confirm that all six PBIs show the correct Feature parent.

You can now trace every Feature and PBI back to Release 4.2: Global Payroll Expansion. The early command centre shows a release that appears broadly on track.

That is the planning foundation complete. Next, you will test this healthy-looking release against operating evidence.

Expose the Hidden Release Risk

The hierarchy you built makes the release look organized. It also makes the release appear broadly on track.

Leadership still cannot see evidence that could force a scope decision. This step turns that blind spot into a visible control signal in Azure Boards.

In this step, get ready to:

Test whether the current portfolio exposes operational danger.
Convert new operating evidence into a shared query chart.
Publish the risk chart on a team dashboard.

Test the healthy-looking portfolio

Before you check, predict whether the current board gives leadership a visible reason to narrow the release.

Switch back to the Azure DevOps Services tab from earlier.
Select Boards in the left navigation.
Select Boards from the submenu.
Inspect the visible cards for a defect or delivery blocker.

The board shows approved scope plus a committed country pilot. No visible defect or blocker challenges that reassuring picture.

That shortfall is intentional. Planned status alone makes the release look safer than the operating evidence supports.

A Bug captures the payroll defect. Separate Impediment work items capture each delivery blocker.

Select Work Items under Boards.
Select New Work Item.
Choose Bug.
Enter Singapore contractor payroll totals round incorrectly in the title field.
Select Save.

The payroll defect now has its own work item. That is the first hidden release signal surfaced.

Create an Impediment named Payroll vendor certification delayed 10 business days by repeating the same New Work Item flow.
Create an Impediment named Single payroll-adapter maintainer with no APAC backup by repeating the same New Work Item flow.

You should now see one Bug plus two unresolved Impediments in the work-item list. The release risk spans product quality, an external dependency, and knowledge concentration.

DORA metrics give leaders a shared view of delivery throughput plus instability. Here they provide synthetic operating evidence for the steering decision.

Select Backlogs under Boards.
Select Epics from the backlog selector.
Open Release 4.2: Global Payroll Expansion.
Place your cursor after the existing controlled-country-pilot business outcome in the Description field.
Preserve the existing text as you add the snapshot by pasting this content below it:

synthetic DORA snapshot
change lead time: 12 days
deployment frequency: 1 per week
failed deployment recovery time: 9 hours
change fail rate: 18%
deployment rework rate: 14%
These are exercise inputs, not industry benchmarks.

What does this snapshot show?

The change lead time plus deployment frequency describe delivery throughput.
The failed deployment recovery time shows how long recovery takes after a failed deployment.
The change fail rate plus deployment rework rate expose instability.
The figures belong only to this fictional management simulation.

Select Save.
Review the saved Description.

You should see the original business outcome followed by all five metrics. Strong work. The Epic now carries the operating evidence that its portfolio hierarchy was missing.

Snapshot missing after saving?

Reopen Release 4.2: Global Payroll Expansion. Confirm that the snapshot was added to the Description field.

Check that the existing controlled-country-pilot outcome remains above the snapshot.

Help me restore the Epic description without losing the existing business outcome.

Turn evidence into management information

A query applies one repeatable filter to the project's work items. Saving it under Shared Queries lets its chart become leadership-facing evidence.

Select Boards in the left navigation.
Select Queries.
Select New.
Select New query.
Confirm that the query type is Flat list of work items.
Set the filter field to Work Item Type.
Set the filter operator to In.
Choose Bug plus Impediment as the filter values.

Before you run the query, predict how many matching rows it will return.

Run the query using the editor toolbar.

You should see three rows. The results contain the payroll Bug plus both Impediments.

Use the query toolbar to save the query as Release Risks.
Choose Shared Queries as the save destination.
Select the Charts tab.
Select New chart.
Set the chart name to Release Risks.
Choose Column as the chart type.
Set Group by to Work Item Type.
Save the chart.

You should see one column for Bug plus one column for Impediment. The Bug count is one. The Impediment count is two.

Charts tab unavailable?

Confirm that Release Risks uses the Flat list of work items query type. Other query types do not support charts.

Confirm that the query is stored under Shared Queries before adding its chart to a dashboard.

Help me make the Charts tab available for my Azure Boards Release Risks query.

Build the command-centre dashboard

A team dashboard keeps the shared risk signal visible outside the query editor. Leadership can now see the evidence without reconstructing your filter.

Select Overview in the left navigation.
Select Dashboards.
Select New dashboard.
Enter Release Command Centre as the dashboard name.
Choose Team Dashboard as the dashboard type.
Select Create.

You should see the new Release Command Centre dashboard ready to receive the risk chart.

Return to Boards in the left navigation.
Select Queries.
Expand Shared Queries.
Open Release Risks.
Select the Charts tab.
Open the actions menu for the Release Risks chart.
Select Add to dashboard.
Choose Release Command Centre.

Before you refresh, predict whether the dashboard will separate the Bug from the Impediments.

Select Overview in the left navigation.
Select Dashboards.
Select Release Command Centre.
Refresh the browser tab.

You should see the Release Risks chart with both Bug and Impediment work items. That is the control signal leadership was missing. The release risk is now visible in one shared command-centre view.

Risk chart missing from the dashboard?

Return to the query's Charts tab. Confirm that the chart actions menu lists Release Command Centre as the selected dashboard.

Check that Release Risks remains saved under Shared Queries.

Help me add my Release Risks query chart to the Release Command Centre dashboard.

Your command centre now exposes the defect, delivery blockers, and weak recovery evidence that the original portfolio concealed. Next up, you will turn those risks into release gates plus a defensible conditional go or no-go decision.

Make the Conditional Go Decision

Your Release Command Centre in Azure DevOps Services now exposes the payroll defect, vendor delay, and single-maintainer risk to leadership.

Evidence alone does not control a release. The earlier plan needs a decision that changes scope and assigns ownership.

You will select a recoverable architecture approach. You will also turn quality, support, and people controls into conditions for release.

In this step, get ready to:

Record a phased architecture decision with assumptions, trade-offs, and a review date.
Create release-gate Tasks with accountable roles and required completion evidence.
Re-scope the country pilot and document the conditional go decision.

Record the architecture decision

An architecture decision records the option selected and the reasoning behind it. A review date keeps the decision open to new evidence.

What the decision must capture

Section heading: Architecture Decision.
Selected approach: Phased country rollout using an asynchronous adapter boundary and reconciliation.
Rejected approach: Full synchronous all-country cutover.
Assumptions: The UK pilot can proceed independently. Singapore remains blocked by vendor certification and payroll defect closure.
Trade-offs: The phased boundary adds reconciliation work. It isolates the uncertified dependency and preserves a controlled recovery path.
Review date: your architecture review date.

Switch back to the Azure DevOps Services project from earlier.
Select Boards in the left sidebar.
Select Backlogs.
Choose Epics from the backlog selector.
Open Release 4.2: Global Payroll Expansion.

The Epic is the durable decision record for the release. Its existing synthetic metrics remain unchanged as exercise inputs.

Append the architecture decision record above beneath the synthetic snapshot in Description.
Select Save.
Refresh the Epic work item.
Confirm that Architecture Decision appears beneath the synthetic snapshot.

Good work. The release now has a documented recovery path instead of an untested all-country cutover.

Architecture decision not saved?

Reopen Release 4.2: Global Payroll Expansion from the Epics backlog.
Confirm that you added the record to Description before selecting Save.

Help me check why my Azure Boards Epic description did not retain the architecture decision.

Define the release gates

A release gate ties permission to proceed to evidence that someone can verify. Accountable roles make each gate owned without requiring fictional user accounts.

Use This Gate Ownership Map

Automated regression suite passes. Parent: Enforce automated regression and rollback gates. Accountable role: QA Lead. Acceptance evidence: automated regression completion evidence.
Rollback rehearsal completed. Parent: Enforce automated regression and rollback gates. Accountable role: Release Manager. Acceptance evidence: rollback-rehearsal evidence.
Monitoring and alert ownership confirmed. Parent: Publish the support runbook and escalation map. Accountable role: Operations Lead. Acceptance evidence: confirmed monitoring and alert ownership.
Support runbook and escalation map approved. Parent: Publish the support runbook and escalation map. Accountable role: Support Operations Lead. Acceptance evidence: approved support runbook and escalation map.
APAC cross-training completed. Parent: Cross-train APAC operations. Accountable role: APAC Operations Lead. Acceptance evidence: proof that an APAC backup is trained.

Return to the Backlog items backlog.
Open Enforce automated regression and rollback gates.
Select Add link.
Select New item.
Set Link type to Child.
Set Work Item Type to Task.
Enter Automated regression suite passes as the title.
Enter Accountable role: QA Lead. Acceptance evidence: Attach automated regression completion evidence before this gate closes. in Description.

Select Add link to create the child Task.

You should see the new Task linked beneath the regression and rollback PBI. Its work item ID confirms that Azure Boards created a separately trackable gate.

Create Rollback rehearsal completed as a child Task under Enforce automated regression and rollback gates by repeating the same child-item flow.
Enter Accountable role: Release Manager. Acceptance evidence: Attach rollback-rehearsal evidence before this gate closes. in Description.
Confirm that Rollback rehearsal completed appears beneath its parent PBI.
Create Monitoring and alert ownership confirmed as a child Task under Publish the support runbook and escalation map by repeating the same child-item flow.
Enter Accountable role: Operations Lead. Acceptance evidence: Record the confirmed monitoring and alert owner before this gate closes. in Description.
Confirm that Monitoring and alert ownership confirmed appears beneath its parent PBI.

The quality and monitoring controls now have named owners and evidence requirements. Leadership can inspect each gate as a separate work item.

Create Support runbook and escalation map approved as a child Task under Publish the support runbook and escalation map by repeating the same child-item flow.
Enter Accountable role: Support Operations Lead. Acceptance evidence: Record approval of the support runbook and escalation map before this gate closes. in Description.
Confirm that Support runbook and escalation map approved appears beneath its parent PBI.
Create APAC cross-training completed as a child Task under Cross-train APAC operations by repeating the same child-item flow.
Enter Accountable role: APAC Operations Lead. Acceptance evidence: Attach evidence that an APAC backup is trained before this gate closes. in Description.
Confirm that APAC cross-training completed appears beneath its parent PBI.

You have converted five expectations into owned controls. The cross-training gate now addresses the concentration of payroll-adapter knowledge directly.

Task Missing From Its Parent?

Open the missing Task from Boards.
Select Links.
Confirm that the intended PBI appears as the Parent link.
Add the intended PBI as the Parent if the Task is unparented.

Help me repair an unparented Azure Boards Task without changing the other release gates.

Commit the conditional release scope

A conditional go permits a limited release only when named conditions hold. The portfolio must show the same boundary as the written decision.

Return to the Backlog items backlog.
Open Pilot UK and Singapore payroll adapters.
Replace the title with Pilot UK payroll adapters.
Update Description to Run the controlled UK payroll-adapter pilot..
Update Acceptance Criteria to UK pilot satisfies the release gates recorded in the Epic..
Leave the existing Effort and Business Value unchanged.
Leave State set to Committed.
Select Save.

You should see Pilot UK payroll adapters with a Committed state. The accepted scope now covers the controlled UK pilot.

Choose Features from the backlog selector.
Open Product and Architecture.

Singapore remains visible as future scope. Its separate PBI preserves accountability without allowing it into the current pilot.

Select Add link.
Select New item.
Set Link type to Child.
Set Work Item Type to Product Backlog Item.
Enter Singapore payroll adapters as the title.
Enter Next release window. Blocked until vendor certification and payroll defect closure. in Description.
Leave State set to New.
Select Add link to create the PBI.

You should see Singapore payroll adapters linked beneath the Product and Architecture Feature.

Confirm that the Singapore PBI remains in New.

Add the Final Decision Record

Section heading: Release Gates. Conditions: critical defect closed. Automated regression evidence attached. Rollback rehearsal completed. Monitoring owner confirmed. Support runbook approved.
Section heading: People and Support Plan. Conditions: APAC backup trained. Accountable roles and completion evidence are recorded on the five child Tasks.
Section heading: Decision: Conditional Go. Decision: Conditional Go for UK pilot. No-Go for Singapore until certification and payroll defect closure.

Return to Release 4.2: Global Payroll Expansion in the Epics backlog.
Append the three final decision sections above beneath Architecture Decision.
Select Save.

Before you refresh the Epic, which country do you expect to remain blocked?

Refresh the Epic work item.
Confirm that Architecture Decision appears in Description.
Confirm that Release Gates appears in Description.
Confirm that People and Support Plan appears in Description.
Confirm that Decision: Conditional Go appears in Description.

What Should You See?

The Architecture Decision section selects the phased country rollout. It records the asynchronous adapter boundary and reconciliation approach.
The Release Gates section requires defect closure, regression evidence, rollback evidence, monitoring ownership, and support approval.
The People and Support Plan section requires a trained APAC backup. The child Tasks identify accountable roles.
The Decision: Conditional Go section permits the UK pilot. It blocks Singapore until certification and payroll defect closure.
The synthetic DORA snapshot remains clearly labelled as exercise input. Its values remain unchanged.

That is the management control loop closed. Your release scope now matches the risks, gates, and accountable ownership recorded in the command centre.

Decision Sections Missing?

Reopen the Epic from the Epics backlog.
Confirm that all four headings are inside Description.
Select Save after restoring any missing section.

Help me compare my Azure Boards Epic decision record with the required conditional go sections.

Your conditional go decision now ties release scope to evidence and ownership. Next, you will convert this command-centre record into an executive steering brief.

Produce the Executive Steering Brief

Your Azure Boards command centre now holds a defensible conditional release decision. Leadership still needs that evidence shaped into a briefing they can absorb quickly.

Claude can accelerate the first draft. Human review keeps the facts anchored in Azure Boards. It also keeps accountability with you before the result reaches PowerPoint for the web.

In this step, get ready to:

Measure a manual release summary against an AI-assisted first draft.
Record a human-validated AI pilot scorecard in Azure Boards.
Deliver a reviewed six-slide steering brief through PowerPoint for the web.

Measure the productivity experiment

A useful productivity experiment compares the same task under two conditions. Your manual six-line summary provides the baseline for judging the AI-assisted result.

What goes into the baseline?

Give each line one purpose. Keep every claim grounded in the fictional release evidence from Azure Boards.

Line 1 covers the executive recommendation.
Line 2 covers business scope plus the roadmap.
Line 3 covers the architecture decision.
Line 4 covers quality, DORA, plus operational readiness.
Line 5 covers the people plus support plan.
Line 6 covers the decisions required from the steering committee.

Start a timer on your device.
Draft the six-line release summary in a temporary note using only the evidence recorded in Azure Boards.
Stop the timer after completing the sixth line.
Record the elapsed value here: your baseline minutes.

Your baseline now measures the human effort behind a concise release narrative. That gives the AI-assisted result a fair comparison point.

Switch back to the Claude Free tab from earlier.
Start a second timer for the AI-assisted workflow.
Paste this steering-brief request into the Claude chat box:

Create a six-slide PowerPoint presentation in .pptx format for a steering committee. Use only the fictional release facts below. Label every assumption. Do not add unsupported facts.

Slide 1: Executive recommendation. Use this exact recommendation: Conditional Go for UK pilot; No-Go for Singapore.
Slide 2: Business scope and roadmap. Show the committed UK pilot. Show Singapore in the next release window.
Slide 3: Architecture decision. Explain the phased country rollout using an asynchronous adapter boundary and reconciliation. Leave clearly labelled fields for the assumptions, trade-offs, and review date from Azure Boards.
Slide 4: Quality, DORA, and operational readiness. Use only these synthetic exercise metrics: change lead time 12 days, deployment frequency 1 per week, failed deployment recovery time 9 hours, change fail rate 18%, and deployment rework rate 14%. Show the active payroll defect, the 10-business-day certification delay, and the release gates.
Slide 5: People and support plan. Show APAC cross-training, monitoring ownership, and support runbook approval. Leave clearly labelled fields for the accountable roles recorded in Azure Boards.
Slide 6: AI pilot scorecard and decisions required. Include labelled fields for baseline minutes, AI-assisted minutes, factual corrections, privacy-check result, and adoption recommendation. Ask the steering committee to confirm the UK pilot conditions. Keep Singapore blocked until certification and payroll defect closure.

Use concise executive language. Separate confirmed facts, assumptions, risks, and decisions required. Do not invent names, dates, status changes, customers, or financial impacts. Create the file for download.

How does this request control the draft?

The six slide purposes keep the briefing focused on a steering decision. The factual boundaries tell Claude where the source evidence ends.

Labelled fields protect details that were recorded in Azure Boards but were not copied into the request. You will replace those fields during human validation.

Submit the request to Claude.
Keep the second timer running while Claude creates the presentation.
Confirm that Claude provides a six-slide .pptx file for download.

You now have an AI-assisted first draft with a visible six-slide structure. The next check determines whether that speed produced trustworthy management information.

No presentation file?

Confirm that the file-creation capability from your earlier setup remains enabled. Ask Claude to create the same six-slide content as a downloadable PowerPoint file.

If Claude Free has reached its usage limit, create a blank presentation in PowerPoint for the web. Copy the validated six-slide content from the chat into that presentation.

The evidence review remains mandatory in either path. Help me troubleshoot a missing Claude PowerPoint file.

Govern the AI-assisted result

The NIST AI RMF provides four lenses for evaluating the pilot. These lenses connect efficiency to ownership, stakeholder impact, measurement, plus human control.

How do the four functions apply?

Govern covers ownership plus acceptable use.
Map covers the reporting use case plus affected stakeholders.
Measure covers time saved, factual corrections, plus rework.
Manage covers human review plus stop conditions.

Switch back to Azure DevOps Services from earlier.
Open the Release 4.2: Global Payroll Expansion Epic.
Compare every presentation metric with the synthetic DORA snapshot in the Epic.
Compare every blocker with the active Bug plus Impediment work items.
Compare every accountable role with the matching release-gate Task.
Compare every release condition with the Decision: Conditional Go section.
Compare the recommendation with the recorded UK pilot decision.
Record the required factual changes here: your verified corrections.

A correction is useful pilot evidence. It shows how much human review the AI-assisted workflow still requires.

Count the factual corrections in your review.
Record the total here: your factual correction count.
Regenerate the presentation with this request if your review found factual discrepancies:

Revise the presentation using these verified corrections from Azure Boards:
[[VERIFIED_CORRECTIONS="your verified corrections"]]

Keep the six-slide structure. Keep this recommendation exactly: Conditional Go for UK pilot; No-Go for Singapore. Remove every unsupported claim. Preserve clearly labelled fields for details that still require manual insertion. Create a corrected .pptx file for download.

What does this correction request do?

The request gives Claude a bounded correction list from the source record. It preserves the agreed structure plus recommendation while removing unsupported claims.

Stop the second timer when the validated .pptx becomes available.
Record the elapsed value here: your AI-assisted minutes.
Confirm that the Claude conversation contains only fictional scenario data.
Record the check here: your privacy-check result.
Form an adoption recommendation from the timing plus review evidence.
Record the recommendation here: your adoption recommendation.

Return to the Pilot AI-assisted release summaries Product Backlog Item in Azure Boards.
Add the pilot result to its description by pasting this record:

AI Productivity Pilot Results
Baseline minutes: [[BASELINE_MINUTES="your baseline minutes"]]
AI-assisted minutes: [[AI_ASSISTED_MINUTES="your AI-assisted minutes"]]
Factual corrections: [[FACTUAL_CORRECTIONS="your factual correction count"]]
Privacy check result: [[PRIVACY_CHECK_RESULT="your privacy-check result"]]
Adoption recommendation: [[ADOPTION_RECOMMENDATION="your adoption recommendation"]]

NIST AI RMF Considerations
Govern: Record ownership and acceptable use for AI-assisted release reporting.
Map: Record the reporting use case and affected stakeholders.
Measure: Compare time saved, factual corrections, and rework.
Manage: Require human review and define stop conditions for unsupported or sensitive output.

What does this pilot record prove?

The timing values measure productivity. The correction count measures the review burden.

The privacy result plus adoption recommendation make the decision auditable. The NIST AI RMF considerations preserve human accountability.

Save the updated Product Backlog Item.
Confirm that all five pilot-result values appear in its description.
Confirm that the description includes Govern, Map, Measure, plus Manage considerations.

Good work. Your productivity claim now includes measured time, correction evidence, privacy controls, plus a documented adoption decision.

Pilot result feels hard to score?

Use the timer values as the efficiency evidence. Use the correction count as the quality evidence.

Keep the adoption recommendation conditional if human review found material rework. Help me interpret my AI pilot results.

Deliver the steering brief

The validated draft now needs a stable file name plus a reviewable home. OneDrive provides that shared presentation path.

Return to the Claude Free tab.
Download the validated .pptx file from the response.
Open your Downloads folder in Finder on macOS or File Explorer on Windows.
Rename the downloaded file to Global-SaaS-Release-Steering-Brief.pptx.
Switch back to your OneDrive tab.
Select Add new.
Select Files upload.
Choose Global-SaaS-Release-Steering-Brief.pptx from your Downloads folder.

Select Open to upload the file.

You should see Global-SaaS-Release-Steering-Brief.pptx in OneDrive. The file name now identifies the release plus its steering purpose.

What remains before presenting?

Claude structured the first draft. Your final review replaces labelled fields with verified values from Azure Boards.

The presentation is ready only when every metric, blocker, owner role, condition, plus recommendation traces back to the command centre.

Open Global-SaaS-Release-Steering-Brief.pptx from OneDrive.
Select Edit Presentation if the file opens in Reading view.
Select Edit in PowerPoint for the web.
Replace each labelled field with the matching verified value from Azure Boards.
Correct any remaining wording issues.
Correct any remaining visual issues.
Confirm that the presentation contains exactly six slides.

Before you begin the slide show, do you expect every slide to trace back to a recorded fact or decision?

Select Slide Show in PowerPoint for the web.
Select From Beginning.

Confirm that slide 1 gives the UK pilot a conditional go while keeping Singapore at no-go.
Confirm that slide 2 places the committed UK pilot in the current scope.
Confirm that slide 2 places Singapore in the next release window.
Confirm that slide 3 presents the phased architecture decision plus its recovery path.
Confirm that slide 4 presents synthetic DORA metrics plus operational release gates.
Confirm that slide 5 presents the people plus support plan with accountable roles.
Confirm that slide 6 presents the AI pilot scorecard plus steering decisions required.
Confirm that no slide introduces an unsupported fact.

The slide show now matches the source record in Azure Boards. No slide introduces a new fact.

You have done the hard part: your six-slide brief now turns a complex release into a defensible steering decision.

Secret mission

Replan After a Late Vendor Delay

A critical vendor dependency has slipped by four weeks. Rebaseline the command centre around a UK-only pilot and deliver a one-minute escalation that keeps the dashboard and steering brief consistent.

Clean Up Your Resources

Choose whether to keep your work available, pause by signing out, or remove every resource. Your browser-based resources stay at $0 within the confirmed free Basic allocation for Azure DevOps Services.

Resources you used:

Global SaaS Release Command Centre private Scrum project. It contains every command-centre artifact created during the exercise.
Claude Free conversation containing only fictional scenario data. It also contains the validated briefing material.
The Global-SaaS-Release-Steering-Brief.pptx presentation stored in Microsoft OneDrive. You reviewed it in Microsoft PowerPoint for the web.

Keep everything running

No action is needed. Choose this option if you want to keep the command centre available for future interview practice or release-governance rehearsals.

Retain the private Global SaaS Release Command Centre project as management-simulation evidence.
Keep the vendor-certification Impediment active until its accountable owner closes it.
Keep the Claude Free conversation limited to fictional scenario data.
Retain Global-SaaS-Release-Steering-Brief.pptx in OneDrive for future briefing rehearsals.

Pause - I'll come back to this later

This exercise has no running compute to shut down. Your project, conversation, and presentation remain unchanged while you are signed out.

Sign out of Azure DevOps Services.
Sign out of Claude Free.
Sign out of Microsoft 365.

Delete - I don't want to use this again

Removing everything clears the practice evidence from your accounts, so choose this option only when you no longer need the simulation. Azure DevOps Services lets you restore a web-deleted project for up to 28 days.

Delete the Azure DevOps project:

Switch back to Azure DevOps Services from earlier.
Select Organization settings.
Select Projects.
Select Global SaaS Release Command Centre.
Select Delete.
Enter Global SaaS Release Command Centre.
Confirm the deletion.

You return to the project list without Global SaaS Release Command Centre. Every Azure Boards artifact inside the project is removed with it.

Delete the Claude conversation:

Switch back to Claude Free from earlier.
Locate the fictional release-simulation conversation in your chat history.
Delete the conversation from its conversation menu.

The fictional release-simulation conversation no longer appears in your chat history.

Delete the OneDrive presentation:

Switch back to OneDrive from earlier.
Locate Global-SaaS-Release-Steering-Brief.pptx.
Delete the file from its file actions.

The presentation no longer appears in your OneDrive files.

Nice Work!

You did it! You built a software operations command centre in Azure Boards that turns fragmented release evidence into a defensible UK-only scope decision.

What you learned:

Built a cross-functional command centre that brings every management area into one release view. Used a portfolio hierarchy to make scope visible from the Epic through each Product Backlog Item.
Used synthetic DORA metrics to assess delivery performance. Converted each visible release risk into a named gate with an accountable role. Documented a conditional release decision that protects the UK pilot while deferring blocked Singapore scope.
Ran a governed Claude productivity experiment using fictional data. Applied the NIST AI RMF to measure value under human validation. Produced a reviewed six-slide steering brief in PowerPoint for the web that communicates the evidence plus the required stakeholder actions.
Secret Mission: Replanned the release after a four-week vendor delay. Kept the dashboard aligned with the revised steering brief. Delivered a one-minute escalation that separates confirmed facts from assumptions. Made the remaining risks plus the required steering decision clear.

Ready to quiz yourself?