Scrum & Azure DevOps for AI Agents

Full-day interactive training | Trainer scripts included | Hands-on lab walkthrough

Fresh-grad AI teams 6-8 hours Interactive + Live exercises Devācārya Training
Scrum Fundamentals
Trainer Script (5 mins)

"Welcome everyone. Today we're exploring Scrum—a framework for building products in short cycles. You're fresh from college, skilled in Python and AI. Scrum isn't magic; it's structure that lets teams move fast without chaos.

Here's the reality: your Apachita agent project has multiple moving pieces—Sourcing, Logistics, Quality agents. Without process, you'd step on each other's code, miss deadlines, and burn out. Scrum fixes that with three simple pieces: roles, ceremonies, and artifacts."

What is Scrum?
Scrum is a lightweight, iterative framework for managing product development. It emphasizes transparency, inspection, and adaptation. Instead of building everything at once, you deliver value in short cycles called sprints (usually 1–2 weeks), gather feedback, and refine your approach continuously.

For your AI agent team, Scrum helps you ship working features (e.g., an agent orchestration layer, a new workflow), get feedback from stakeholders, and pivot quickly if something isn't working.
Scrum Roles (Three Core Roles)
Trainer Script (10 mins)

"Scrum has three roles. Think of them as hats. Each person wears one hat—they can't wear two at once because it creates conflicts of interest."

Product Owner: "They own the 'what' and 'why.' Their job is to know the business. They decide: Should we build vendor priority sorting or SHG feedback collection first? They live with stakeholders, understand the market."

Scrum Master: "They own the 'how'—process, not technical decisions. They're like a coach. If you're blocked on WhatsApp API credentials, they chase the issue. If someone's exhausted from 12-hour sprints, they protect the team."

Dev Team: "That's you. Self-organizing. You decide 'we'll pair on the LangGraph refactor.' You estimate complexity. You commit to delivery."

Owns the "what" and "why".
  • Defines the vision: What features should the AI agent build? (e.g., "Agents should autonomously source floral waste from vendors.")
  • Prioritizes the backlog: Which features matter most? Rank them by business value.
  • Clarifies requirements: Explains user stories and acceptance criteria to the team.
  • Accepts completed work: Verifies that delivered features meet the definition of done.
Example: "We need the Sourcing Agent to prioritize SHG women vendors in Q3. This feature is worth 21 story points and should be in Sprint 5."
Owns the "how" (process, not technical).
  • Removes blockers: Your agent's WhatsApp integration is down? The SM chases the Twilio ticket.
  • Facilitates ceremonies: Runs standups, sprint planning, retros. Keeps meetings on time.
  • Coaches the team: Teaches Scrum practices; watches for anti-patterns (e.g., skipping retros, ignoring velocity).
  • Protects the team: Shields developers from scope creep mid-sprint.
Example: "The agent's LangGraph is too slow. Let's block time to refactor before we add new workflows. I'll talk to the PO about re-prioritizing."
Owns the "build".
  • Self-organizing: The team decides how to build the feature, no one is "assigned." You collaborate to figure it out.
  • Cross-functional: Ideally, the team has all skills needed—backend (Python, FastAPI), infra (Azure), ML (LangGraph), etc.
  • Commits to the sprint: You forecast story points and commit to delivering them by sprint end.
  • Communicates constantly: Daily standups, pair programming, code reviews.
Example: "We can build the Handoff agent in 8 points if we reuse the state machine from Sourcing. Let's pair on the MCP server integration."
Scrum Ceremonies (Events)
Trainer Script (8 mins)

"Scrum is all about rhythm. There are four ceremonies—think of them as checkpoints. Each has a purpose and a time limit."

Sprint Planning: "Start of sprint. 'What are we building this sprint?' PO talks about priorities, team estimates, we agree on a goal."

Daily Standup: "15 mins, every morning. Not a status report. You answer: What did I do? What's next? Any blockers? If blocked, we fix it after standup."

Sprint Review: "Demo day. We show stakeholders what we built. They give feedback. We update the backlog based on feedback."

Retrospective: "Team only. No stakeholders. What went well? What was hard? What will we do differently next sprint?"

🗓️ Sprint Planning

When: Start of sprint.
Duration: 2–4 hours.

Team + PO discuss backlog items. Team forecasts story points and commits to a sprint goal.

📊 Daily Standup

When: Every morning.
Duration: 15 mins.

Each dev answers: What did I do? What am I doing? Any blockers? Not a status report—a sync.

🔄 Sprint Review

When: End of sprint.
Duration: 1–2 hours.

Team demos finished work to stakeholders. Gather feedback. Update the backlog.

🔍 Sprint Retrospective

When: After review.
Duration: 1–1.5 hours.

Team reflects: What went well? What didn't? What will we improve next sprint?

Scenario: Your team is 2 months into building the Apachita Bio Aggregators agents (Sourcing, Logistics, Quality, Handoff, Payment).

Sprint Goal: "Enable the Sourcing agent to autonomously fetch SHG vendor data from WhatsApp and validate it."

Backlog Items (prioritized by PO):
  1. Refactor WhatsApp listener (ReAct pattern) — 13 points (Epic dependencies)
  2. Implement vendor data validation (MCP call) — 8 points
  3. Add telemetry to agent state transitions — 5 points
  4. Bug fix: MemorySaver not persisting state — 3 points
Team Forecast: 20 story points (based on velocity from last 3 sprints).

Decision: Take items 1, 2, 4 (13+8+3=24 points). This is a stretch but the PO and team agree—item 3 can wait.
Scrum Artifacts
Trainer Script (5 mins)

"Artifacts are the 'stuff' of Scrum. Three main ones: the Product Backlog, Sprint Backlog, and the Increment (what you deliver)."

Product Backlog: "Master list. Every feature, bug, improvement—ranked by business value. Owned by the PO. Never 'done'—always growing."

Sprint Backlog: "A slice of the Product Backlog. 'This sprint, we're tackling these items.' Once sprint starts, don't add. Protect your commitment."

Increment: "The working stuff. At the end of each sprint, you have a complete, tested, deployable slice. Not a prototype—something you can run in production."

📦 Product Backlog
A prioritized list of all features, bugs, and improvements the product should have. Owned by the PO. Example items:
  • As an SHG group, I want the Sourcing agent to auto-fetch my collection schedule so I don't have to enter it manually.
  • As a system, I need the Logistics agent to handle vendor no-shows gracefully.
  • Performance: Reduce agent inference latency to <2s for real-time WhatsApp responses.
🎯 Sprint Backlog
Items committed for the current sprint. A snapshot of the Product Backlog for this sprint. Owned by the Development Team. Once a sprint starts, don't add new items—protect the team's focus.
✅ Increment (or "Done Increment")
All completed, tested, deployable work from the sprint. At the end of each sprint, you should have a working agent feature (or a slice of one) that could go to production. This is the goal of Scrum—ship value every sprint.
Key Scrum Principles
🔍 Transparency
Everyone sees the backlog, sprint board, and blockers. No surprises.
🔄 Inspection
Regular demos, reviews, retros. Measure velocity, burndown, quality metrics.
🛠️ Adaptation
Change backlog priorities, improve processes, pivot based on feedback.
Azure DevOps Fundamentals
Trainer Script (5 mins)

"Azure DevOps is your Scrum digital home. It's built by Microsoft and it understands Scrum natively. Think of it as GitHub + Jira + CI/CD in one place."

"You get: a backlog to track stories, a board to visualize your sprint, Git repos for code, and pipelines to automate testing and deployment. All connected."

Why Azure DevOps for Scrum?
Azure DevOps is a project management + CI/CD platform built by Microsoft. It integrates with Scrum natively and gives you:
  • Work Items & Boards: Track user stories, bugs, tasks in a visual Kanban/Scrum board.
  • Repos: Git repositories for version control (alternative to GitHub, though GitHub is also great).
  • Pipelines: Automated CI/CD—build, test, deploy your agent code every time you push.
  • Test Plans: Test management, traceability.
Work Items & Backlog
Trainer Script (10 mins)

"Azure DevOps organizes work as 'Work Items.' You'll see Epic, Feature, User Story, Task, and Bug."

User Story: "This is the smallest, most important unit. 'As a vendor, I want to reply to the agent via WhatsApp so I can sell my waste directly.' Clear, testable, valuable."

Story Points: "We estimate complexity, not time. Use Fibonacci: 1, 2, 3, 5, 8, 13. A 1-pointer? 'Add logging.' An 8-pointer? 'Refactor WhatsApp listener with ReAct.' A 13-pointer? That's probably too big—split it."

Work Items are units of work you track in Azure DevOps. Common types:
  • Epic: A large feature spanning multiple sprints. E.g., "AI agent autonomous vendor discovery."
  • Feature: A subset of an Epic. E.g., "WhatsApp listener with ReAct pattern."
  • User Story: A small, testable requirement from the end user's perspective. E.g., "As a vendor, I want to respond to agent queries via WhatsApp."
  • Task: A technical subtask. E.g., "Set up Azure Service Bus message queue," or "Write unit tests for agent state machine."
  • Bug: Something broken. E.g., "Agent loses context after 10 messages."
Format: "As a [role], I want [action], so that [benefit]."

Example (Good):
As a Sourcing agent, I want to validate vendor SHG registration data against a national database, so that we only work with verified, compliant vendors. Acceptance Criteria: ✓ Agent calls the SHG registry MCP server with vendor ID. ✓ API returns ✅ (verified) or ❌ (not found). ✓ Agent logs result to Azure Table Storage for audit. ✓ If unverified, agent replies via WhatsApp: "Vendor not registered. Please contact support."
Example (Vague—don't do this):
"Make agent smarter." ❌
Too vague. How? Which agent? What does "smarter" mean? How do we test it?
Story Points estimate effort and complexity, not time. Use a scale (Fibonacci: 1, 2, 3, 5, 8, 13, 21, etc.).

Rough Guide (for your Python/AI team):
  • 1–2 pts: Quick win. E.g., "Add logging to agent state transitions." One engineer, 1–2 hours.
  • 3–5 pts: Small feature. E.g., "Build MCP server wrapper for SHG registry lookup." 1–2 engineers, 1–2 days.
  • 8 pts: Medium feature. E.g., "Refactor WhatsApp listener with ReAct pattern." Team effort, 3–4 days.
  • 13+ pts: Large/risky feature. Probably should be split. E.g., "Build end-to-end Sourcing agent" is 21 pts—break into smaller stories.
💭 Planning Poker Exercise
Story: "Integrate Razorpay payment webhook for vendor SHG payments."
How many points? (Hint: Consider—setting up webhook listener, validating signatures, updating agent state, error handling, testing.)
Answer: Likely 8 points (involves multiple systems, error cases, security). If you have a payment specialist, might be 5.
Backlog view (Azure DevOps): Shows all work items, prioritized top-to-bottom.

Typical workflow:
  1. Backlog Refinement (grooming): PO + team review top backlog items, discuss unclear stories, estimate, ensure they're "sprint-ready."
  2. Sprint Planning: Team picks items from the top of the backlog, moves them to the "Sprint X Backlog" and commits.
  3. During Sprint: Dev team pulls from Sprint Backlog, moves items through board states: To Do → In Progress → In Review → Done.
  4. Sprint Close: Any unfinished items go back to Product Backlog.
💡 Key: The backlog is always in priority order. The top item should be the next thing the team pulls.
Sprint Board & Kanban
Trainer Script (8 mins)

"The Sprint Board is your daily command center. You see columns: To Do, In Progress, In Review, Done."

"At the start of a sprint, all your committed items are in 'To Do.' During the day, you move cards across columns as you work. By day 5, everything should be in 'Done.'"

"The burndown chart shows your progress. If it's flat—not moving—that signals blockers. Raise them in standup."

Visual Work Tracking
Azure DevOps Boards show a Kanban board—columns represent stages of work.

Typical columns:
📋 To Do 🔨 In Progress 👀 In Review ✅ Done
Example—Your team's sprint board:
  • To Do (5 items): WhatsApp listener refactor, vendor validation MCP, state machine tests, etc.
  • In Progress (2 items): You're working on the ReAct pattern refactor and the MCP integration.
  • In Review (1 item): A teammate's code for the state machine—waiting for your review.
  • Done (4 items): Tasks completed this sprint—vendor data model, telemetry logging, CI/CD setup, etc.
Sprint Burndown Chart: Shows remaining story points over the sprint days. Goal: line goes down to zero by sprint end.

Velocity: Total story points completed per sprint. Helps you forecast future sprints.
20
Sprint points committed
18
Sprint velocity (avg last 3)
5
Days in sprint
4 pts/day
Ideal burndown rate
💡 Tip: If your burndown is flat (no progress), that signals blockers. Bring them up in standup—the SM will help unblock.
Case Study: Apachita Bio Aggregators Agent
Trainer Script (15 mins)

"Let's walk through a real example: your Apachita project. You have a PO, fresh-grad engineers, a complex agent architecture. How do you ship fast without chaos?"

"Scrum + Azure DevOps is the answer. You break the Apachita roadmap into 2-week sprints. Each sprint, you commit to building a slice of an agent."

"Sprint 1: 'Sourcing agent MVP.' Sprint 2: 'Add validation.' Sprint 3: 'Quality checks.' By Sprint 6, you have a full system. And you shipped working pieces on day 10, not on day 60."

"Why does this matter? Stakeholders see progress early. You get feedback. The team stays motivated. You can pivot if the market changes."

🌿 The Problem

Your team is building an AI agent platform for circular economy floral waste management. You have a Product Owner (business stakeholder), fresh-grad engineers, and a complex agent architecture (Sourcing, Logistics, Quality, Handoff, Payment agents). How do you ship fast without chaos?

✨ The Scrum + Azure DevOps Solution

Sprint 1: "Sourcing Agent MVP"
Goal: Agent autonomously listens to SHG WhatsApp messages and extracts collection data.
Stories:
  • US-2401: WhatsApp listener with Twilio (8 pts)
  • US-2402: LangGraph state machine for message parsing (13 pts)
  • US-2403: Persist state to Redis (5 pts)
Velocity: 20 pts committed, 18 completed. ✅
Sprint 2: "Validation & Handoff"
Goal: Agent validates vendor data against SHG registry, hands off to Logistics agent.
Stories:
  • US-2404: SHG registry MCP server (8 pts)
  • US-2405: Validation logic (5 pts)
  • US-2406: Agent handoff via Azure Service Bus (8 pts)
  • BUG-2401: MemorySaver not persisting between sessions (3 pts)
Velocity: 22 pts committed. 20 completed (blocked on external API). ⚠️
Sprint 3: "Quality Checks & Monitoring"
Goal: Quality agent inspects floral waste photos, logs metrics.
Stories:
  • US-2407: Image analysis with GPT-4o Vision (13 pts)
  • US-2408: Panchangam (auspicious timing) lookup for pickup (5 pts)
  • US-2409: Azure Monitor telemetry (3 pts)
Velocity: 21 pts. ✅

🔄 How You Avoided Chaos

  • Sprints enforced priorities: Instead of everyone building random features, the PO ranked agents (Sourcing first, then Logistics). Clear sequence.
  • Velocity tracking prevented burnout: By sprint 2, you saw you consistently do 20 pts/sprint. Sprint 3 forecast = 20 pts. Realistic.
  • Retros helped iterate: Sprint 2 retro: "We were blocked by the SHG API. Let's mock it in dev, build a mock MCP server." Next sprint, no blockers.
  • PR reviews caught bugs early: CI/CD caught a Docker build error before it hit production. Saved hours of debugging.
Putting It All Together: Scrum + DevOps Workflow
Trainer Script (5 mins)

"Here's your rhythm for a 2-week sprint."

"Day 1, 9 AM: Sprint Planning. You commit to 20 story points. Day 2–5: You code. Every morning, 10 AM standup. Every PR triggers Azure Pipelines—tests run, Docker builds, staging deployment. Day 5 PM: Demo to stakeholders. Then retro."

"Repeat. Every sprint, you ship something real. Every sprint, you learn."

Day 1 of Sprint: 9 AM Sprint Planning. PO + team meet. Discuss backlog, estimate, commit.

Days 2–4: Daily standup 10 AM. Dev team pulls stories, works on feature branches.

During: Code reviews on PRs. Azure Pipelines tests everything. Deploy to staging.

Day 5 (End): Sprint Review (demo to stakeholders) + Sprint Retro (team reflection).
📋 Sprint Planning
🔨 Daily Dev
Code → PR → Review → Test → Deploy
👀 Sprint Review
Demo to stakeholders
🔍 Retro
Improve next sprint
Hands-on Exercises
Exercise 1: Create a User Story
Scenario: Your team needs to build a "Feedback Collection" feature for the Payment agent. SHG groups should receive a WhatsApp message after payment asking: "How was your experience?"

Task: Write a user story in Azure DevOps format.

Template:
As a [role], I want [action], so that [benefit]. Acceptance Criteria: - [ ] ... - [ ] ... - [ ] ...

Sample Answer:
"As a Payment agent, I want to send a satisfaction survey via WhatsApp 5 minutes after a successful payment, so that we gather real-time feedback from SHG groups."

Acceptance Criteria:
  • ✓ Agent waits 5 minutes after payment webhook confirmation
  • ✓ Sends predefined WhatsApp template: "How was your Apachita experience? Reply 😊, 😐, or ☹️"
  • ✓ Logs response to Azure Table Storage tagged with payment_id
  • ✓ If no response in 24h, don't re-send (avoid spam)
Exercise 2: Estimate Story Points
You are estimating for your next sprint. Three stories are proposed:

Story A: "Add logging to agent state transitions" (Python, ~50 lines).
Story B: "Build Panchangam lookup MCP server" (Python + API integration, new dependencies).
Story C: "Refactor LangGraph workflow for 5 agents" (Complex, affects multiple systems).

Task: Assign story points (1, 2, 3, 5, 8, 13, 21) to each.

Sample Answer:
  • Story A: 2 points — Quick win. One engineer can knock it out in a few hours. Low complexity, low risk.
  • Story B: 5 points — Medium. You need to call an external API (Panchangam service). Handle errors, test edge cases (leap years, Andhra holidays). Dependencies to add. But straightforward—1–2 days.
  • Story C: 13 points — Large. Touches 5 agents. Risk of regression. Testing is complex. Needs team collaboration. 4–5 days. Or split into smaller stories.
Exercise 3: Identify Blockers in Standup
Standup script:

Engineer A: "Yesterday I finished the WhatsApp listener. Today I'm starting the vendor validation. No blockers."

Engineer B: "I finished unit tests. I'm waiting for Engineer C's MCP server code to do integration tests. I'm kind of blocked..."

Engineer C: "I'm waiting for the SHG API credentials from the PO. Can't start the MCP server without them."

Task: As Scrum Master, what do you do?

Answer:
  • Blocker 1 (Engineer C): "I'll email the PO right now. We need those SHG API credentials by EOD today. If they're not available, let's use a mock API—Engineer B, can you help Engineer C set up a mock MCP server in the next 2 hours so C can unblock?"
  • Blocker 2 (Engineer B waiting on C): "While C works on the mock, B: can you write the integration test spec? So when the real MCP server is ready, tests just plug in."
  • Follow-up after standup: Check with PO on the API credentials. Remove the blocker. Keep the team moving.
Key Takeaways
1. Scrum is a rhythm
Sprints, standups, retros. Repeat. Inspect & adapt.
2. User stories = clarity
Good stories prevent miscommunication and rework.
3. Velocity = realism
Track what you complete, forecast honestly.
4. DevOps = safety net
CI/CD catches bugs, automates deploys.
5. Transparency builds trust
Everyone sees the board, blockers, progress.
6. Retros drive improvement
What went well? What to change? Act on it.
Live Lab: Setting Up Your First Azure DevOps Project
Trainer Script (20 mins)

"Now we're getting hands-on. I'm going to walk you through creating your Azure DevOps project from scratch. You'll follow along on your laptops. By the end, you'll have a live backlog and sprint board for your AI agent team."

"We'll cover: creating a project, setting up your first user story, creating a sprint, and assigning work to team members. Then you'll practice on your own."

Part 1: Create an Azure DevOps Organization & Project
1

Go to Azure DevOps

Open dev.azure.com in your browser. Sign in with your Microsoft account (or create one if needed).

https://dev.azure.com
2

Create an organization

Click "Create new organization." Name it something like apachita-agents or myteam-devops.

Note: You only do this once per team. If your org already exists, skip to "Create project."

3

Create a project

Click "+ New project." Name it Apachita-Sprint-1 (or your agent project name).

Visibility: Choose "Private" (only team members can see).

Version control: Choose "Git".

Work item process: Choose "Scrum".

ℹ️ "Scrum" process gives you Epics, Features, User Stories, Tasks, Bugs—exactly what we need.
4

Wait for project to initialize

Azure DevOps creates the project (takes ~30 seconds). You'll see a welcome page with tabs: Boards, Repos, Pipelines, etc.

Part 2: Create Your First Epic & User Stories
5

Go to Backlog

Click the Backlog tab on the left sidebar. You'll see an empty backlog with no items yet.

6

Create an Epic

Click "+ New Work Item" → select "Epic." Name it "Sourcing Agent MVP".

Title: Sourcing Agent MVP Description: Agent autonomously listens to SHG WhatsApp messages and extracts collection data.

Click "Save." The Epic appears at the top of your backlog.

7

Create first User Story

Click "+ New Work Item" → select "User Story." Name it:

Title: WhatsApp listener with Twilio integration Description: As a Sourcing agent, I want to listen to incoming WhatsApp messages from SHG groups, so that I can receive collection requests in real-time. Acceptance Criteria: - Agent connects to Twilio WhatsApp Business API - Receives and parses inbound messages - Logs all messages to Azure Table Storage - Responds with confirmation: "Got it, we'll process your waste"

Click "Save." The story appears in your backlog.

💡 Tip: Right-click the story and select "Link work item." Choose the Epic you created. This groups related stories.
8

Add story points

Click on the story you just created. In the right panel, look for "Effort" or "Story Points." Set it to 8.

Click "Save."

9

Create 2–3 more stories

Repeat steps 7–8 for these stories:

Story 2: "LangGraph state machine for message parsing" (13 pts)
Story 3: "Persist conversation state to Redis" (5 pts)

Your backlog now shows: Epic → 3 stories (8+13+5=26 pts).

Part 3: Create & Plan Your Sprint
10

Go to Sprints

Click the Sprints tab (or "Boards" → "Sprints" if it's nested). You'll see a sprint planning view.

11

Create a new sprint

Click "+ New sprint." Name it "Sprint 1 - Sourcing MVP".

Sprint duration: 2 weeks (10 working days).

Click "Create."

12

Drag stories into the sprint

Go back to Backlog. You'll see your stories on the left, Sprint 1 on the right.

Drag your 3 stories into Sprint 1. (Total: 26 points.)

💡 Real scenario: Your team averages 20 pts/sprint. 26 is a stretch, but doable if you're confident.
13

View the sprint board

Click the sprint name. You'll see a Kanban board with columns: To Do, In Progress, Review, Done.

All 3 stories start in "To Do."

Part 4: Assign Work & Simulate a Sprint Day
14

Assign stories to team members

Click on the first story ("WhatsApp listener"). In the right panel, click "Assigned to" and select a team member (or yourself for testing).

Assign Story 1 to Engineer A, Story 2 to Engineer B, Story 3 to Engineer A.

15

Simulate Day 1 of the sprint

Drag Story 1 from "To Do" to "In Progress." (Engineer A started working on WhatsApp listener.)

Drag Story 2 to "In Progress." (Engineer B started the LangGraph state machine.)

16

Simulate Day 3 (progress)

Drag Story 1 to "In Review." (Engineer A finished WhatsApp listener, waiting for code review.)

Notice the board: 1 in review, 1 in progress, 1 in to-do.

17

Simulate Day 5 (sprint end)

Drag Story 1 to "Done." (Code review approved.)

Drag Story 2 to "Done." (LangGraph state machine completed.)

Move Story 3 to "In Progress" (last-minute push).

Result: 2 stories done (8+13=21 pts), 1 in progress (5 pts). Velocity this sprint: 21 pts (close to your 20-pt average).

🎬 End-of-Sprint Activity (Real-World Walkthrough)

Sprint Review (4 PM, Day 5): Engineer A demos the WhatsApp listener. Stakeholders ask: "What if a vendor doesn't respond for an hour?" You add a task: "Implement message timeout." Added to next sprint's backlog.

Retro (5 PM): Team discusses:

  • What went well: "Pair programming on LangGraph helped us ship faster."
  • What was hard: "Twilio API docs were confusing; wasted 2 hours on auth."
  • 🔄 Next sprint: "Allocate 2 hours for third-party API research at the start."

Outcome: You move Story 3 back to the backlog (unfinished = normal). You have 2 shipped features + real feedback + a process improvement. You've shipped working software in 10 days.

Part 5: Linking Git & Azure Pipelines (Optional)
Trainer Script (10 mins)

"Now we link code to stories. When you commit code with a story ID in the message, Azure DevOps auto-links it. When your PR merges, the story moves to Done."

18

Create a Git repo in Azure DevOps

Click the Repos tab. Click "+ New repository." Name it apachita-agents.

Copy the HTTPS URL (for cloning).

19

Clone & create a feature branch

git clone https://dev.azure.com/[org]/apachita-agents/_git/apachita-agents cd apachita-agents git checkout -b feature/US-1-whatsapp-listener

(Replace "US-1" with your actual story ID, visible in Azure DevOps.)

20

Make a commit & link the story

echo "print('Hello from WhatsApp listener')" > listener.py git add listener.py git commit -m "Feat: Initialize WhatsApp listener module - Fixes US-1" git push origin feature/US-1-whatsapp-listener

Key: The commit message includes "Fixes US-1" (or "Closes US-1"). Azure DevOps detects this and links the commit to your story.

21

Create a pull request (PR)

In Azure Repos, click "Create a pull request." Select your feature branch.

Title: "Feat: WhatsApp listener with Twilio - Closes US-1"

Click "Create." The PR links to story US-1 automatically.

Tip: Add a code reviewer from your team. They review & approve. Then merge.

22

Watch the story auto-move

Go back to your Sprint Board. When you merge the PR, the story automatically moves to "Done."

Magic: No manual updates. Work item + code + CI/CD = fully connected.

✅ You've Completed the Live Lab!
You now have:
  • ✓ An Azure DevOps organization & project
  • ✓ A product backlog with Epics & stories
  • ✓ A sprint with 3 committed stories
  • ✓ A sprint board (Kanban view)
  • ✓ Git integration (commits auto-link to stories)
  • ✓ Experience simulating a real sprint

Next step: Repeat this setup for your real Apachita project. Invite your team. Start Sprint 1 on [date]. Run daily standups. Demo on day 10. Retro. Repeat.

Common Pitfalls & How to Avoid Them
Problem: "Improve agent" is not a story. No one knows what to build or how to test it.

Solution: Write specific stories. "As a Sourcing agent, I want to validate vendor SHG registration, so we only work with compliant vendors." Clear role, clear action, clear benefit.
Problem: PO adds new stories to the sprint on day 3. Team gets distracted. Nothing ships on time.

Solution: Once sprint starts, lock it. New requests go to the backlog. Protect the sprint commitment. Sprint is sacred.
Problem: Standup runs 45 mins. People zone out. Blockers don't get resolved.

Solution: 15-minute timer. If a blocker needs discussion, table it: "Let's sync on WhatsApp API auth after standup. Let's not block the whole team." Standup = sync, not deep-dive.
Problem: Team ships Sprint 1. Moves to Sprint 2 without reflecting. Same mistakes repeat.

Solution: Retro is mandatory. 1 hour, team only. "What went well? What didn't? What will we change?" Pick ONE improvement and commit to it next sprint. By Sprint 3, your process is smoother.
Problem: You estimate a story as 5 pts. It takes 3 days. Your velocity is garbage. Forecasts are wrong.

Solution: First sprint, calibrate. Track how many pts you actually complete. By Sprint 3, you know: we do 18–22 pts per 2-week sprint. Estimate based on that baseline. Refinement happens—that's normal.
Resources & Next Steps
For your team:
  • ☑️ Set up Azure DevOps project for Apachita (today, after training).
  • ☑️ Invite all team members. Assign roles: 1 PO, 1 SM, 3+ engineers.
  • ☑️ Create the Epics for your roadmap: Sourcing, Logistics, Quality, Handoff, Payment.
  • ☑️ Write 15–20 user stories for the first 2 sprints.
  • ☑️ Schedule Sprint 1 Planning for [date]. Target: 2 hours.
  • ☑️ Daily standup: every weekday, 10 AM, 15 mins.
  • ☑️ Sprint Review + Retro: day 10 of each sprint, 2 hours total.

Further learning: