LS 301

Agile Delivery & Backlog Strategy

LS 301 deepens your role as a Product Owner by focusing on agile delivery rhythms, backlog architecture, and the systems thinking needed to move teams from chaos to coherent flow.

From tickets and tasks to orchestrated delivery systems.
Jump to a Lesson
Select a core lesson or its mastery studio. Each pair stacks the lesson above its “.1” application lab.
Lesson 1
Agile Frameworks in Context
Learning goal: situate Scrum, Kanban, and hybrid models within real-world delivery environments.

Learners compare agile frameworks through the lens of flow, constraints, and how the Product Owner drives clarity in each.

  • Differentiate Scrum, Kanban, and common hybrids in enterprise environments.
  • Clarify the Product Owner’s responsibilities across frameworks.
  • Recognize anti-patterns that break flow (ticket factories, “Scrum-fall,” bottlenecks).
  • Framework snapshots: Scrum, Kanban, dual-track agile.
  • Short case studies of teams “doing agile” poorly vs. well.
  • Discussion: mapping your current team’s reality to these patterns.
  • Complete a “My Team Today” agile self-audit.
  • Identify where the Product Owner role is under- or over-extended.
  • Short reflection: which framework best describes your team’s behavior today and why?
  • List of 2–3 concrete agile improvement opportunities tied to the PO role.
This lesson meets the learning goal by giving you a realistic map of agile options and clarifying where you live on that map today.
Lesson 1.1
Mastery Studio: Mapping Your Delivery System
Mastery focus: visually map your team’s delivery system and identify friction points.

Learners construct a current-state map of their delivery lifecycle, from idea to shipped increment, and critique it with peers.

  • Create a swimlane or kanban-style map of how work really flows on your team.
  • Mark handoffs, blockers, rework, and communication gaps.
  • Peers ask clarifying questions about hidden queues and approval cycles.
  • Group surfaces patterns that suggest which framework tweaks might help.
  • Map accurately reflects actual team behavior, not just the ideal process.
  • Learner can articulate 2–3 candidate changes to improve flow from the PO vantage point.
Mastery shows up in your ability to see your system clearly and speak about change in precise, pragmatic terms.
Lesson 2
Backlog Architecture & User Story Craft
Learning goal: design a backlog that is navigable, meaningful, and aligned to outcomes.

Learners go beyond “list of tickets” thinking into a structured backlog that reflects epics, features, and stories tied to value.

  • Distinguish epics, features, and user stories with clear vertical slicing.
  • Write user stories and acceptance criteria that support testability and shared understanding.
  • Align backlog items to outcomes instead of internal structures alone.
  • Example teardown: unclear vs. clear story, with ADTL-style annotation for clarity and cognitive load.
  • Mini-lecture on INVEST criteria and acceptance criteria patterns.
  • Story tree / opportunity solution tree overview.
  • Refactor a flat list of tasks into epics → features → stories.
  • Rewrite 2–3 stories using a shared template and explicit acceptance criteria.
  • Backlog slice that visually shows structure and intent.
  • Stories that could be understood by UX, engineering, and stakeholders without further translation.
This lesson meets the goal by turning your backlog into a designed information space, not a dumping ground.
Lesson 2.1
Mastery Studio: Story Clinic & Backlog Refactor
Mastery focus: apply story craft to your own backlog items.

Learners bring real backlog items, perform a structured rewrite, and critique each other’s work as a delivery team would.

  • Select 3–5 real backlog entries from your current environment.
  • Rewrite them using user story + acceptance criteria patterns.
  • Group them under a meaningful epic/feature umbrella.
  • Peers read your stories as if they were engineers/UX and highlight confusion or ambiguity.
  • Group explores how these stories might break down for implementation and testing.
  • Stories are testable, user-centered, and small enough to be realistically delivered.
  • Backlog structure reflects outcomes and navigability rather than organizational silos alone.
Mastery is evident when your backlog reads like a designed narrative of value rather than a log of chores.
Lesson 3
Prioritization & Value Sequencing
Learning goal: prioritize work using value, risk, and effort—not just loudest voice.

Learners explore tools like WSJF, cost of delay, and value vs. effort mapping to design a prioritization system that fits their context.

  • Compare prioritization approaches: MoSCoW, RICE, WSJF, Kano, and qualitative stakeholder input.
  • Link prioritization to product strategy and quarterly outcomes.
  • Recognize patterns of “priority inflation” and executive thrash.
  • Mini-lecture: cost of delay and sequencing for learning vs. revenue.
  • Interactive exercise plotting items on a value vs. effort matrix.
  • Discussion: what makes a prioritization scheme legitimate in your org?
  • Assign sample scores to a small backlog using a chosen framework (e.g., WSJF).
  • Re-order a backlog based on that scoring and defend the sequence.
  • A sample prioritized backlog with rationale attached.
  • Written reflection: how would you explain this sequence to a skeptical stakeholder?
This lesson ensures that your backlog sequence isn’t arbitrary—it’s narrated, defensible, and strategically coherent.
Lesson 3.1
Mastery Studio: Prioritization Council Simulation
Mastery focus: defend prioritization decisions in a simulated stakeholder forum.

Learners present a prioritized slice of backlog to a mock “prioritization council” and navigate challenges to their decisions.

  • Prepare a short backlog prioritization narrative (“Why this, why now?”).
  • Respond to “what about my item?” type objections using agreed criteria instead of politics alone.
  • Peers offer feedback on clarity, data use, and alignment to strategy.
  • Group reflects on emotional dynamics of saying “not yet” or “no.”
  • Decisions are justified with reference to value, risk, and capacity.
  • Learner can stay calm, clear, and consistent under pressure.
Mastery is evidenced by principled prioritization in the face of competing pressures—not just theory on paper.
Lesson 4
Estimation, Capacity & Forecasting
Learning goal: collaborate with teams to estimate, plan capacity, and set realistic expectations.

Learners examine story points, cycle time, and capacity planning as tools for transparent delivery forecasting rather than false precision.

  • Understand common estimation approaches (story points, t-shirt sizing, no-estimates).
  • Use historical data to guide planning, not dictate it.
  • Communicate uncertainty and risk when discussing timelines.
  • Mini-lecture: why estimates go wrong and what to do instead.
  • Walkthrough of sample velocity/cycle time charts.
  • Practice constructing a “low/likely/high” forecast for a body of work.
  • Estimate a small set of stories as a group using 2 approaches.
  • Create a simple forecast scenario tied to a sprint or quarter.
  • Documented forecast including assumptions and risk flags.
  • Draft talking points for an executive conversation about timeline confidence.
This lesson helps you speak about time and capacity with mathematical humility and strategic clarity.
Lesson 4.1
Mastery Studio: Forecast Walkthrough & Feedback
Mastery focus: present a forecast and respond to “Can we go faster?”

Learners present a forecast scenario and practice fielding common challenge questions from leadership and teams.

  • Present a forecast including assumptions, constraints, and potential accelerators.
  • Respond to “What if we just add more people?” and similar prompts with systems thinking.
  • Peers evaluate clarity of explanation and realism.
  • Group identifies where additional data or visualization would help.
  • Learner is honest about uncertainty without sounding evasive.
  • Forecast communicates trade-offs rather than promises.
Mastery appears when you can protect teams from unrealistic commitments while still moving outcomes forward.
Lesson 5
Sprint & Flow Rituals as Design
Learning goal: design sprint events and flow rituals that actually generate insight and alignment.

Learners treat ceremonies—planning, daily syncs, reviews, retros—as designed experiences, not calendar obligations.

  • Clarify purpose, inputs, and outputs of each agile event.
  • Identify when events have become status meetings instead of decision forums.
  • Apply ADTL thinking to the “feel” and structure of each ritual.
  • Compare “default” vs. intentionally designed sprint events.
  • Discuss psychological safety, inclusion, and cognitive load in meetings.
  • Brainstorm small changes that could transform one event on your team.
  • Audit your current event cadence and identify what’s working vs. performative.
  • Draft a redesign for one key event (e.g., sprint review) including agenda, visuals, and decision points.
  • Documented “before and after” event design for one ritual.
  • List of expected behavioral shifts from the redesign.
This lesson reframes agile rituals as intentional containers for attention, not recurring calendar noise.
Lesson 5.1
Mastery Studio: Ritual Redesign & Facilitation Plan
Mastery focus: present and refine a redesigned agile ritual.

Learners share a redesigned sprint event or flow ritual and walk peers through how it will change team behavior and delivery outcomes.

  • Present agenda, timings, visuals, and facilitation prompts for the redesigned event.
  • Explain how this design addresses known pain points (boredom, confusion, lack of decisions).
  • Peers role-play as participants and respond to the event flow.
  • Group suggests micro-adjustments to pacing, visuals, or prompts.
  • Event design clearly ties to desired cognitive and emotional outcomes.
  • Learner can articulate how ritual changes will show up in delivery metrics and morale.
Mastery is seen in your ability to choreograph how people experience time, attention, and decisions in agile rituals.
Lesson 6
Delivery Metrics & Continuous Improvement
Learning goal: interpret key delivery metrics and design improvement experiments.

Learners examine metrics like cycle time, lead time, throughput, and burndown, learning how to translate them into narrative, insight, and action.

  • Understand what cycle time, lead time, WIP, and throughput really mean in practice.
  • Connect metrics to actual lived experience of teams and customers.
  • Use metrics to generate hypotheses for process improvements rather than blame.
  • Tour of sample dashboards (boards, burndowns, control charts).
  • Mini-lecture on “vanity metrics” vs. decision-driving metrics.
  • Group practice: answering key questions using provided metric snapshots.
  • Interpret a set of metric snapshots and write a 1–2 paragraph “story of the system.”
  • Propose 1–2 small improvement experiments grounded in metric evidence.
  • Written interpretation of metrics that avoids blame and focuses on system design.
  • Draft improvement experiments aligned with those interpretations.
This lesson shifts metrics from fear and punishment into mirrors for thoughtful, Aletheian improvement.
Lesson 6.1
Mastery Studio: Delivery Storytelling & Improvement Plan
Mastery focus: narrate your delivery system and design a concrete improvement arc.

Learners build and present a short “delivery story” using their own or sample metrics and outline a 60–90 day improvement plan.

  • Present a visual or narrative walkthrough of recent delivery metrics.
  • Explain what those numbers likely feel like for team members and stakeholders.
  • Outline a lightweight improvement roadmap with 2–3 experiments.
  • Peers reflect on clarity, empathy, and practicality of the plan.
  • Group suggests refinements and additional data that might be helpful.
  • Learner can connect metrics, team experience, and process design in one coherent story.
  • Improvement plan is specific, time-bound, and realistic in their context.
Final mastery in LS 301 is shown in your ability to see your delivery system, narrate it, and lead it into a better next iteration.