Agile and Scrum Fundamentals for Teams is a course in Agile thinking and the Scrum framework, from the Product Owner and Scrum Master roles and user stories to sprint planning with story points, reviews and retrospectives, with a simulated sprint in class. It suits software teams, project managers and team leads, and anyone about to take on a Scrum role.
Many organizations say they have adopted Agile, yet in practice they end up with more meetings, work that still ships late and a team that is unsure what to do first. The problem is rarely the tooling. It is not understanding what Agile and Scrum actually solve and what each ceremony is for. This course builds a genuine Agile foundation and then works through the Scrum framework piece by piece: the responsibilities of the
product owner, scrum master and developers, managing the product backlog and writing user stories that teams can act on, sprint planning and estimation with story points, the daily and per-sprint ceremonies, measuring progress with velocity and burndown charts, and the problems teams hit when they start for real. Learners run a full simulated sprint from planning through retrospective in class. (2 days, 6 hours per day, 12 hours in total, Beginner to Intermediate level.)
Course Details
A 2-day course, 6 hours per day (12 hours in total), delivered as lectures with group workshops throughout. Beginner to Intermediate level. Learners take home a ready-to-use template set covering user stories, definition of done, sprint planning and retrospectives, plus the workshop output their own team produced. The course follows the latest Scrum Guide and is not tied to any particular tool.
Section 1: Agile Thinking and Its Origins
Why long up-front plans with a single delivery at the end break down
The Agile Manifesto values and principles and what they mean in practice
Common misconceptions: Agile is neither the absence of planning nor simply working faster
An overview of the Agile frameworks in real use and where Scrum sits among them
Section 2: The Structure of Scrum
Every element of Scrum: the accountabilities, the events and the artifacts
Working in short sprints and why something usable must ship each round
Transparency, inspection and adaptation as the heart of Scrum
How each event connects into one complete sprint cycle
Section 3: Roles and Responsibilities
Product owner: deciding on value and the order of the work
Scrum master: helping the team flow and removing impediments
Developers: shared accountability for what the sprint delivers
How roles map onto real organizations and the traps of overlapping responsibilities
Section 4: Product Backlog and User Stories
Building and maintaining a product backlog that is always ready to work from
Writing user stories that convey value with clear acceptance criteria
Splitting large work down small enough to finish inside one sprint
Workshop: write user stories from your own real work and review them together
Section 5: Prioritization and Sprint Planning
Prioritization techniques you can justify to management and users
Setting a sprint goal that points the whole team in one direction
Sprint planning: selecting the work and agreeing a definition of done
Workshop: order your backlog and plan your team first sprint
Section 6: Estimating with Story Points
The difference between estimating in hours and estimating in story points
Using planning poker to get the team aligned on size
Handling work that cannot be estimated and using spikes to reduce uncertainty
Workshop: estimate your backlog with planning poker
Section 7: Daily Scrum and Working Through the Sprint
Running a daily scrum that stays short, useful and never becomes a status report
Using the board so the team sees real status and blocked work
Handling interruptions and change during a sprint
Removing impediments and escalating problems at the right moment
Section 8: Sprint Review and Retrospective
Running a sprint review that produces feedback the team can actually act on
Running a retrospective where people speak honestly and one real change comes out
Retrospective formats that work and how to vary them so the team stays engaged
Workshop: run a simulated retrospective and list the changes you will make
Section 9: Measurement and Visibility
Velocity: what it really means and using it to plan, not to rate people
Reading burndown and burnup charts to see the trend of a sprint
Other metrics worth watching, such as cycle time and accumulated work in progress
Measurement traps that push teams to game the numbers instead of creating value
Section 10: Common Problems in Early Adoption
What to fix first when the team misses its plan every sprint
What to do when management still wants a long-term plan and a fixed date
What to do when team members are split across several projects
Adapting Scrum to your organization without losing the principles that matter
Section 11: Capstone and Adoption Plan
Capstone: plan and simulate one full sprint from planning to retrospective
Present your sprint goal, backlog and definition of done
A first-30-days plan for starting Scrum in your organization and what to avoid
Workshop: present your adoption plan and get feedback from the instructor
No public rounds are open right now. Join the waiting list and we will contact you first when the next round opens, or ask us on LINE. Or call 02-570-8449 or 088-807-9770
Scrum has three roles. The Product Owner is accountable for product value, manages the product backlog and decides priorities. The Scrum Master helps the team use Scrum well, facilitates events and removes impediments. The Developers are everyone who builds the work, sharing responsibility for delivering a usable increment that meets the Definition of Done every sprint. The Scrum Master is not a manager who assigns tasks.
Use the format: as a (user), I want (capability) so that (value), which shows who benefits and why. Then write testable acceptance criteria, for example in Given, When, Then form, and split stories that are too big into pieces that can be finished within one sprint. Check each story against INVEST: independent, negotiable, valuable, estimable, small and testable.
Story points size work relative to other work, combining effort, complexity and uncertainty, often using Fibonacci-style numbers such as 1, 2, 3, 5 and 8. Estimates in hours depend on who does the work and tend to be wrong when the work is uncertain. Teams often use Planning Poker, where everyone reveals a card at once and discusses differences, and use velocity for planning, not for judging individuals.
It suits software teams about to start or just starting with Scrum, project managers and team leads who want a more flexible way of managing work, people taking on the Product Owner or Scrum Master role, and business teams working with Agile developers. No Agile, Scrum or programming knowledge is needed, though experience of team projects helps you relate the ideas to your work.
You will be able to explain Agile principles and the Scrum framework, define clear roles, write user stories with acceptance criteria, order a backlog, plan a sprint with a sprint goal and Definition of Done, estimate with Planning Poker, run effective daily scrums, sprint reviews and retrospectives, and read burndown charts to track progress. Participants who complete the training receive a Certificate of Completion with its own number, which can be verified online.
Yes. It can be run in-house for your team, with examples adapted to your own work, such as writing user stories from a real team project and simulating your first sprint together. You can request a quotation from this page, or contact us on LINE @itgenius or by phone on 02-570-8449.
Articles are published in Thai.
Planning a project on paper or in an Excel sheet works while the project is small. Once there are dozens of tasks that depend on one another, several people responsible and a budget to control, moving a single task means correcting dates across the whole…
Building and changing infrastructure by hand through a web console creates inconsistency, leaves no audit trail and makes it hard to reproduce an environment. Terraform solves this by expressing infrastructure as code that lives in Git, is reviewed through…
