Agile & Scrum Foundations Course
Five lessons that build Agile and Scrum skills: manifesto principles, roles, events, artifacts, planning, estimation, and scaling.
What you will learn
- Explain the four Agile values and key principles.
- Describe the three Scrum roles and their accountabilities.
- Use Scrum events to create an inspect-and-adapt rhythm.
- Connect Scrum artifacts to their commitments.
- Apply planning, estimation, and scaling concepts in real teams.
Before you start
- Basic knowledge of software teams.
- Interest in project management or product delivery.
- About 75 minutes of study plus regular practice.
Lesson 1 Agile Mindset and Manifesto Principles
The Agile Manifesto values individuals and interactions, working software, customer collaboration, and responding to change. Twelve principles explain how to apply these values: deliver value early, welcome change, collaborate daily, build around motivated people, use face-to-face communication, and reflect regularly. In Agile, process is a tool, not the goal; teams inspect outcomes and adapt quickly. Start by connecting each value to a team behavior you can observe in a real project.
Values to behaviour: turn each manifesto value into an observable team habit. Individuals and interactions means holding short daily conversations, not relying only on tickets. Responding to change means reordering the backlog when new information arrives instead of insisting on the original plan.
Use the principles as a checklist during retrospectives: did we deliver value early, welcome change, collaborate daily, and reflect regularly? Name one improvement for the next sprint after each review.
Example
A team that delivers a small feature every two weeks and adjusts based on customer feedback is applying frequent delivery and customer collaboration.
Worked example: A customer asks for a change during the sprint.
The team checks whether the change is already in the sprint goal. If not, they add it to the product backlog and discuss priority at the next planning session.
This applies the value of responding to change without disrupting the sprint goal.
Lesson 2 Scrum Roles and Responsibilities
A Scrum Team has three accountabilities: one Product Owner, one Scrum Master, and Developers. The Product Owner owns the Product Backlog and maximizes value. The Scrum Master coaches Scrum, removes impediments, and helps the organization understand the framework. Developers are accountable for creating a usable Increment each Sprint and decide how to do the work. There is no project manager role in Scrum; the team self-manages around clear goals.
Accountability test: for any task, ask which role owns it. The Product Owner decides value and priority; Developers decide how to build the increment; the Scrum Master helps the team use Scrum and removes blockers. If a task belongs to no one, the team must decide where to place it.
Remember that accountability is not a job title: a developer can coach another developer, but the Scrum Master accountability remains one person who is accountable for the framework.
Example
The Product Owner decides the next valuable feature; the Developers choose how to build it; the Scrum Master helps remove the blocker.
Worked example: A blocker stops the team from testing a feature.
The Developers explain the blocker at the Daily Scrum. The Scrum Master helps remove it or escalates it, while the Product Owner decides whether the feature is still a priority.
Each role acts on its own accountability.
Lesson 3 Scrum Events and the Sprint
A Sprint is a timebox of one month or less that contains all other Scrum events: Sprint Planning, Daily Scrum, Sprint Review, and Sprint Retrospective. Sprint Planning creates the Sprint Goal and Sprint Backlog. The Daily Scrum is a 15-minute planning session for the Developers. Sprint Review inspects the Increment with stakeholders and updates the Product Backlog. Sprint Retrospective helps the team improve its process. Each event creates a rhythm of inspect and adapt.
Event purpose cards: Sprint Planning creates the goal and plan; Daily Scrum synchronizes the Developers; Sprint Review adapts the product with stakeholders; Sprint Retrospective improves the process. If an event has no clear output, shorten it or change how you prepare.
Use the Sprint as a container: do not start new work that conflicts with the Sprint Goal. When scope must change, cancel the Sprint only after a conversation with the Product Owner.
Example
Sprint Planning answers what and how; the Daily Scrum keeps the team aligned; Sprint Review adapts the product; Retrospective improves the process.
Worked example: During the Sprint, the team discovers a small improvement to the code structure.
They note it in the backlog and finish the Sprint Goal first. At the retrospective, they decide whether to make the improvement next sprint.
This protects the Sprint Goal while capturing the learning.
Lesson 4 Scrum Artifacts and Commitments
The Product Backlog is the ordered list of all product work and its commitment is the Product Goal. The Sprint Backlog is the selected work plus a plan, with the Sprint Goal as its commitment. The Increment is the usable product value produced in a Sprint, and the Definition of Done is its commitment. These artifacts make work transparent, focused, and measurable. Teams refine the backlog continuously so items are clear enough for planning.
Transparency check: at any moment, the Product Backlog should show what to build next, the Sprint Backlog should show what the team is doing, and the Increment should be usable. If any artifact is unclear, refine it before planning.
Use the Definition of Done consistently: an item is not done just because code is written. It must be tested, documented if needed, and accepted by the team before it counts as part of the Increment.
Example
An item is ready for a Sprint when it is clear, valuable, and small enough for the team to estimate and complete.
Worked example: A developer says a user story is done because the code is written.
The team checks the Definition of Done: tests pass, no open review comments, and the feature is usable in the increment.
If any item is missing, the story is not done.
Lesson 5 Agile Planning, Estimation, and Scaling
Agile planning happens at several levels: product vision, Product Goal, release planning, Sprint Planning, and daily planning. Teams estimate with story points or similar relative measures, use velocity to forecast capacity, and refine the backlog before planning. Good user stories follow INVEST: independent, negotiable, valuable, estimable, small, testable. At scale, frameworks such as SAFe, LeSS, and Nexus add coordination without replacing Scrum empirical core.
Estimation practice: compare stories with a known reference item instead of guessing hours. Use story points in Fibonacci-like values, and after each sprint compare planned points with delivered velocity. If velocity is stable, use it to forecast; if not, plan smaller batches.
For scaling frameworks, remember they add coordination layers: SAFe adds program and portfolio levels, LeSS scales one product team, and Nexus coordinates multiple Scrum teams. The empirical loop of inspect and adapt still applies at every level.
Example
A team uses velocity from the last three Sprints to forecast how many story points it can likely deliver next Sprint.
Worked example: The team delivered 18, 20, and 19 story points in the last three sprints.
Their average velocity is 19, so they plan about 19 points for the next sprint and adjust after planning.
If a new item is large, they split it before committing.