Agile Delivery Foundations & Backlog Systems
LS 201 is where Luminous Systems moves from theory into the craft of delivery: sprint rhythm, backlog flow, and the day-to-day mechanics of product ownership in agile environments — through the lens of ADTL.
Learners explore the core values and principles behind agile delivery and how they shape the Product Owner’s daily decisions.
- Differentiate agile values, principles, and frameworks (Scrum, Kanban, etc.).
- Understand where the Product Owner fits in the agile delivery system.
- Connect agile principles to ADTL ideas of iteration, feedback, and clarity.
- Mini-lecture: agile manifesto, principles, and PO responsibilities.
- Comparison activity: “agile theater” vs. authentic agile delivery.
- Discussion: where have you seen agile help or hurt teams?
- Sort real-world practices into “core agile” vs. “optional ritual.”
- Map your current context on a spectrum from command-and-control to agile.
- Short written explanation of agile in your own words.
- List of 2–3 agile principles you want to see more intentionally in your work.
Learners apply agile principles to their real context, identifying alignment, friction, and opportunities for incremental change.
- Map your team or organization’s current delivery style against agile principles.
- Highlight two practices that strongly support agility and two that undermine it.
- Peer review of each map: what rings true, what might be missing?
- Group discussion on how culture, roles, and systems shape agile adoption.
- Learner can describe agile strengths and gaps using real examples.
- Learner can articulate one realistic, next agile improvement in their context.
Learners practice crafting user stories and acceptance criteria that communicate intent, constraints, and value clearly to teams and stakeholders.
- Use the “As a / I want / So that” pattern with nuance, not rigidity.
- Define acceptance criteria that test outcomes, not just completion.
- Understand value slicing: cutting work into learnable, ship-able increments.
- Review of good vs. weak user stories and criteria.
- Mini-lecture on vertical vs. horizontal slices and “walking skeletons.”
- Live rewriting of sample backlog items.
- Rewrite vague tasks into clear stories and criteria.
- Practice slicing one large story into smaller, value-centered increments.
- Set of improved stories and acceptance criteria.
- Short explanation of your slicing decisions for one complex item.
Learners bring real or drafted backlog items and run them through a structured critique and revision process with peers.
- Present 3–5 real or realistic backlog items for review.
- Rewrite them live into full stories with acceptance criteria and value slicing.
- Peers tag strengths and gaps: clarity, value, testability, scope.
- Group explores how different slices could affect learning and risk.
- Learner can reliably produce clear, testable, value-focused stories.
- Learner can defend slicing choices with reasoning tied to risk and learning.
Learners explore what “healthy backlog” really means and how to design refinement practices that support the team instead of draining it.
- Define backlog health signals (age, clarity, duplicates, dependency tangles, etc.).
- Understand ordering vs. prioritization and how to express both.
- Clarify “definition of ready” vs. “definition of done.”
- Mini-lecture on backlog quality metrics and anti-patterns.
- Examples of strong vs. chaotic backlogs.
- Discussion: how refinement is experienced by dev teams today.
- Evaluate a sample backlog using a simple health rubric.
- Draft a “definition of ready” appropriate for your context.
- Backlog health rubric filled in for a provided or real example.
- Documented definition of ready with rationales.
Learners conduct a structured audit and propose concrete changes to improve backlog health for their team or a case scenario.
- Assess an existing backlog against the health rubric.
- Identify at least three high-impact improvements (merging, removing, re-ordering, clarifying).
- Peers react to proposed changes and discuss likely team impact.
- Group explores how to implement improvements without overwhelming the team.
- Learner can differentiate cosmetic changes from real backlog improvements.
- Learner can articulate how backlog changes support sprint planning and focus.
Learners examine how sprint planning, stand-ups, reviews, retrospectives, and Kanban practices work together to create sustainable flow.
- Understand sprint cadence and Kanban flow as design decisions.
- Use WIP (work in progress) limits and policies to protect focus.
- Connect ceremonies to learning loops, not status reporting.
- Visual walkthrough of a sprint or Kanban cycle.
- Discussion of common ceremony anti-patterns (stand-up as status, retro as complaint session, etc.).
- Mini-lecture on WIP limits and flow metrics.
- Sketch your team’s current cadence and policies.
- Identify one place where WIP limits or policy tweaks could improve flow.
- Annotated diagram of your current or ideal sprint/flow system.
- Draft WIP or policy change with rationale.
Learners create and present a small set of flow improvements based on their context, including how to introduce them without chaos.
- Propose 1–3 specific changes to cadence, WIP, or policy.
- Define how you will measure whether each change is helping.
- Peers test proposals against team capacity, culture, and constraints.
- Group explores how to communicate and phase these changes.
- Learner’s proposals are modest, clear, and grounded in context.
- Learner can name specific signals that indicate success or failure.
Learners explore delivery metrics (throughput, cycle time, defects, etc.) and how to use them to inform decisions without overwhelming teams or stakeholders.
- Differentiate vanity metrics from actionable metrics.
- Connect metrics to feedback loops and learning experiments.
- Design simple visualizations that highlight patterns and questions.
- Examples of effective and ineffective agile dashboards.
- Mini-lecture on basic flow and quality metrics.
- Discussion: how metrics shape behavior.
- Select 2–3 key delivery metrics for your context.
- Sketch a one-page delivery snapshot using ADTL-aligned visual design.
- A simple metric set tailored to your product or team.
- Draft visual or dashboard concept with design notes.
Learners build and present a “metric storyboard” that explains what is happening in delivery and what decisions it suggests.
- Create a 1–2 page metric storyboard or slide set.
- Use it to tell a story about flow, quality, and risk over time.
- Peers evaluate clarity, focus, and design of the storyboard.
- Group explores what decisions they would make based on the story.
- Learner can use metrics to frame a decision or experiment.
- Visual design supports comprehension rather than adding noise.
Learners design a simple, visual model of how work will move from idea to production in their team, integrating backlog, cadence, metrics, and feedback.
- Combine stories, backlog practices, cadence, and metrics into one system view.
- Identify where ADTL principles (clarity, aesthetics, culture) show up in delivery design.
- Prepare to communicate this model to teams and stakeholders.
- Review of core LS 201 elements and artifacts.
- Design session: sketching your “delivery blueprint.”
- Peer feedback on clarity and feasibility.
- Create a 1-page delivery system diagram with annotations.
- Highlight where feedback and learning loops occur.
- Completed delivery system blueprint tied to your product or a case.
- List of 2–3 questions you still need to explore with your real team.
Learners present their delivery blueprints, walk peers through LS 201 elements, and refine based on feedback and questions.
- Present your LS 201 delivery blueprint in 5–7 minutes.
- Explain how backlog, cadence, and metrics fit together in your design.
- Peers provide structured feedback on clarity, feasibility, and ADTL alignment.
- Group surfaces risks, assumptions, and opportunities for further iteration.
- Learner can articulate LS 201 concepts through their own system, not just definitions.
- Learner leaves with at least one concrete refinement to implement in their real context.