Day 3: Implementing Scrum: Planning and Execution

Recap & Connection

A brilliantly cut diamond with clear facets, symbolizing the well-defined concepts from the previous day.

Welcome to Day 3! Yesterday we defined the key roles and strategic tools that bring a project to life. Today, we'll focus on how to break down that strategy into actionable work. Let's quickly review the key concepts from Day 2:

• The Scrum Team & Its RolesThe three accountabilities in a Scrum Team: The Product Owner (What), the Scrum Master (How), and the Developers (Do).
• Strategic Tools: Roadmap, MVP, & Critical PathKey tools for planning and strategy: The Product Roadmap (vision), the MVP (first releasable version), and the Critical Path (longest sequence of tasks).
• The Scrum ArtifactsThe three pillars of transparency in Scrum: The Product Backlog, the Sprint Backlog, and the Increment.
• Kanban Flow & WIP LimitsVisualizing work on a Kanban board and using Work In Progress (WIP) limits to improve flow and efficiency.

The Product Backlog (PBL): The Single Source of Truth

An image of a long, antique parchment scroll with text and priority numbers, representing the Product Backlog.

The Product BacklogThe Product Backlog is an ordered list of everything that is known to be needed in the product. It is the single source of requirements for any changes to be made to the product. is a dynamic, ordered list of all the features, functions, requirements, enhancements, and fixes that might be needed in the product. It is the single source of truth for the team's work and is managed by the Product Owner. A good Product Backlog is "DEEP": Detailed appropriately, Estimated, Emergent, and Prioritized.

The Power of Timeboxing

An icon of a calendar with a specific block of time highlighted and boxed in, with a clock inside it, representing a fixed duration for an activity.

TimeboxingTimeboxing is allotting a fixed, maximum unit of time for an activity. That unit of time is called a timebox. is a critical concept in Scrum. It means that every event has a fixed, maximum duration that cannot be extended. The Sprint itself is a timebox, as are all the events within it, like the Daily Scrum (15 minutes). This creates a predictable rhythm, prevents work from dragging on, and forces the team to focus on the most important tasks to achieve their goal within the given timeframe.

Writing Effective User Stories: The INVEST Model

An infographic of a diamond with six facets, each labeled with a letter from the I.N.V.E.S.T. acronym (Independent, Negotiable, Valuable, Estimable, Small, Testable).

The INVESTINVEST is an acronym that stands for Independent, Negotiable, Valuable, Estimable, Small, and Testable. It provides a useful checklist for creating effective user stories. model provides a set of criteria for writing effective user stories. A good user story should be: Independent, Negotiable, Valuable, Estimable, Small, and Testable. By following these guidelines, teams can create user stories that are clear, concise, and ready for development.

Effort Estimation: Planning Poker

A hand holding five cards showing Fibonacci numbers: 1, 2, 3, 5, 8, illustrating the use of Planning Poker.

Planning PokerPlanning Poker is a consensus-based, gamified technique for estimating, mostly used to estimate effort or relative size of development goals in software development. is a popular technique for estimating the effort required to complete user stories. It's a consensus-based approach that uses Story PointsStory points are a unit of measure for expressing an estimate of the overall effort that will be required to fully implement a product backlog item or any other piece of work. and the Fibonacci sequence to reflect the inherent uncertainty in estimating complex work. The entire team participates in the estimation process, which fosters collaboration and a shared understanding of the work to be done.

Functional User Stories: Delivering Value Incrementally

An assortment of different fruits, each with a number tag on it, symbolizing that each piece is a distinct, valuable, and deliverable user story.

Agile focuses on delivering functional, valuable increments of a product. Think of each numbered fruit as a complete User Story that provides value on its own (e.g., "As a user, I want a peeled banana so I can eat it right away"). This is different from a traditional approach that might deliver all the fruit peels first (a non-functional component). By delivering small, complete pieces of value, teams can get feedback from users early and often, ensuring they are building the right product.

Planning Poker Practice

A larger and more complex assortment of fruits, including exotic fruits and berries, representing a more complex user story to be estimated.

Hierarchy of Work: Epic vs. Story

An infographic with a large mountain labeled 'Epic' breaking down into smaller rocks at the base labeled 'User Stories,' representing the work hierarchy.

Work in a Product Backlog is often organized hierarchically. An EpicAn epic is a large body of work that can be broken down into a number of smaller stories. is a large body of work that can be broken down into smaller, more manageable pieces of work called User StoriesA user story is a short, simple description of a feature told from the perspective of the person who desires the new capability, usually a user or customer of the system.. User stories are typically written from the user's perspective and follow the format: "As a [type of user], I want [some goal] so that [some reason].". This hierarchy helps the team to understand the big picture while working on small, incremental pieces of value.

BREAK & Mindset Shift

A coffee cup and a notebook on a wooden table, signifying a break for coffee and discussion.

Let's take a short break. We've covered how to structure the work with backlogs and user stories. When we come back, we'll shift our focus to how we structure the *time* to get that work done by diving into the Scrum events.

The Agile Sprint: The Heartbeat of Scrum

A circular infographic representing the continuous, iterative cycle of an Agile Sprint, with phases for planning, execution, and review.

The Sprint is the central event in Scrum; it's the container for all other events. A Sprint is a fixed-length period, typically one to four weeks long, during which the team works to create a "Done," usable, and potentially releasable product Increment. A new Sprint starts immediately after the conclusion of the previous one, creating a consistent and predictable cadence for development. This steady rhythm helps teams focus, manage their energy, and deliver value to stakeholders on a regular basis.

The Five Scrum Events

An infographic of a calendar showing a highlighted 'Sprint' time box with smaller icons inside for Sprint Planning, Daily Scrum, Sprint Review, and Sprint Retrospective.

The Scrum EventsThe Scrum events are Sprint Planning, Daily Scrum, Sprint Review, and Sprint Retrospective. They are time-boxed events that create regularity and minimize the need for meetings not defined in Scrum. are the heartbeat of Scrum. The Sprint is a time-boxed iteration (usually 1-4 weeks) during which a "Done," usable, and potentially releasable product increment is created. The other four events—Sprint Planning, Daily Scrum, Sprint Review, and Sprint Retrospective—all take place within the Sprint. These events provide the structure for the team to inspect and adapt their work, ensuring that they are always on the right track.

Defining 'Done': The Team's Quality Commitment

A perfectly prepared and presented fruit dish, with fruits arranged in a wave-like pattern, symbolizing a high-quality, complete, and 'Done' product increment.

How does a team know when their work is truly finished? They use the Definition of Done (DoD)The Definition of Done is a formal description of the state of the Increment when it meets the quality measures required for the product.. The DoD is a formal, shared understanding of all the criteria that a User Story must meet before it can be considered complete. This isn't just about coding; it can include testing, documentation, and compliance checks. A strong DoD is crucial for transparency and for ensuring a high-quality, potentially releasable product Increment at the end of every Sprint.

Planning with Data: Capacity & Velocity

An infographic of a roadmap with milestones, symbolizing that capacity and velocity help in long-term planning.

How does a team know how much work to pull into a Sprint? They use data. Team Capacity refers to the team's availability for the upcoming Sprint, considering holidays, appointments, and other commitments. It answers, "How much time do we have?" Team Velocity, on the other hand, is the average amount of work (in Story Points) the team has completed in past Sprints. It's a powerful metric for forecasting and answers, "How much work do we typically get done?" By understanding both, a team can create a realistic Sprint plan and make their long-term roadmaps more predictable.

Sprint Review: Inspecting the Increment

An infographic showing a completed, usable piece of a product (the Increment) being presented, symbolizing the output of a Sprint.

The Sprint ReviewAn informal meeting held at the end of the Sprint to inspect the Increment and adapt the Product Backlog if needed. is a collaborative session where the Scrum Team and stakeholders inspect the IncrementThe sum of all the completed Product Backlog items from a Sprint, representing a step toward a Product Goal.. The team demonstrates the work they have "Done" during the Sprint. This is not a formal status meeting; it's a working session to get feedback on the product. Based on this feedback and changes in the marketplace, attendees collaborate on what to do next, and the Product Backlog may be adjusted to reflect new opportunities.

Sprint Retrospective: The Engine of Improvement

An infographic showing a cyclical arrow, representing the continuous improvement cycle of a Sprint Retrospective.

The Sprint RetrospectiveThe Sprint Retrospective is an opportunity for the Scrum Team to inspect itself and create a plan for improvements to be enacted during the next Sprint. is the final event of the Sprint. Its purpose is to plan ways to increase quality and effectiveness. The Scrum Team inspects how the last Sprint went with regards to individuals, interactions, processes, tools, and their Definition of Done. This is the team's dedicated time for continuous improvement, making it one of the most important events for building a high-performing team.

Preparing for the Afternoon Practical

A hand holding five cards showing Fibonacci numbers: 1, 2, 3, 5, 8, symbolizing the estimation work to come.

This afternoon, you'll put theory into practice. Your group will be responsible for creating a Product Backlog for your assigned scenario, breaking down a large feature (an Epic) into smaller, well-defined User Stories. You will then conduct a simulated Sprint Planning session, using Planning Poker to estimate the effort for your stories. This is your chance to experience the core planning and execution rhythm of a real Scrum team.