Foundation for the agile philosophy and mental shift.
Prioritisation and incremental value delivery.
Shared vision and effective communication.
High-performing teams and collaborative environment.
Iterative planning from roadmap to sprint.
Identify, manage and resolve risks and impediments.
Reflection and refinement of product, process, people.
“Thinking differently to build amazing things, together.”
Welcome to the first step on your Agile journey! This module is like the key that opens the door to a whole new way of working and thinking. Have you ever tried to build a big Lego castle, but you kept changing the design as you went along? That’s a bit like Agile!
In this module, we will learn the heart of Agile: the mindset and the principles. We will discover why Agile is used all over the world, from Nigeria to Japan, to build software, run businesses, and even organise school projects. We will use simple words, fun stories, and lots of examples so that anyone – even a 10-year-old – can understand.
By the end of this module, you will think like an Agile practitioner. You will know how to welcome change, work as a team, and keep improving little by little. Let’s begin!
Imagine you are in a village in Nigeria. Your grandmother gives you a magic cooking pot that can make any stew you dream of. But here is the twist: you don’t know the exact recipe, and the pot changes its taste every hour!
If you try to write down one fixed recipe and never change it, your stew will taste bad. But if you taste the stew every 10 minutes, add a little salt, then some pepper, then maybe a bit of crayfish – you end up with a delicious meal that everyone loves.
That is exactly how Agile works. Instead of planning everything perfectly at the start, we try, learn, and adjust along the way. Agile is like cooking with a magic pot: you keep tasting and improving until it’s just right.
Now let’s learn the ingredients of this magic mindset!
Definition: Agile is a way of working where you deliver small pieces of value quickly, then learn and adapt.
Why important: The world changes fast. Agile helps us keep up and build what people really need.
Simple explanation: Instead of building a whole house at once, you build one room, show it to the family, then build the next room based on their feedback.
Real-life example: A phone app that gets a new feature every two weeks instead of waiting a whole year.
School example: Writing a book report paragraph by paragraph and asking your teacher for advice after each paragraph.
Home example: Cleaning your room one corner at a time, showing your parents, and then cleaning the next corner.
Nigerian example: A small business in Lagos selling “small chops” – they try a new flavour, see if customers like it, then make more.
ASCII illustration:
Traditional way (Waterfall):
Plan ➜ Build ➜ Test ➜ Launch (takes ages!)
Agile way (Iterative):
Plan ➜ Build small ➜ Show ➜ Learn ➜ Plan again ➜ Build more ➜ Show ➜ Learn ...
Definition: A mindset is the way you think about things. The Agile mindset is open, curious, and not afraid of change.
Why important: Without the right mindset, tools and methods won’t work.
Simple explanation: It is like being a scientist in a lab – you try an experiment, see what happens, and try again.
Real-life example: A chef who tastes the soup and adds spices bit by bit.
School example: When you get a math problem wrong, you don’t give up – you try a different way to solve it.
Home example: You rearrange your furniture until it feels just right.
Nigerian example: A tailor who makes a dress, asks the customer to try it on, then adjusts the seams.
Mindset spectrum:
Fixed Mindset ------------ Agile Mindset
“I can’t do it.” “I can learn.”
“Change is bad.” “Change is opportunity.”
In 2001, a group of smart people wrote the Agile Manifesto. It has 4 values. Let’s learn them with easy examples.
| Value | Simple meaning | Example |
|---|---|---|
| Individuals and interactions over processes and tools | People matter more than rules or software. | Talk to your teammate instead of sending 20 emails. |
| Working software over comprehensive documentation | A product that works is better than a huge manual. | A game you can play is better than a 100-page design doc. |
| Customer collaboration over contract negotiation | Work with the customer, don’t fight over terms. | Ask the customer what they want, don’t just follow a strict contract. |
| Responding to change over following a plan | It’s okay to change the plan if you learn something new. | If a new flavour of ice-cream is popular, change the menu! |
Nigerian example: A market woman in Onitsha – she talks to her customers (interaction), sells fresh yams (working product), listens to what they want (collaboration), and changes her prices or stock based on the day (responding to change).
The 12 principles are like the “rules of the road” for Agile. We’ll cover 6 now and 6 later.
Everyday example: You and your friend are building a treehouse. You talk face-to-face (principle 6), you show a small part of the treehouse every day (principle 3), and when your friend says “I want a slide instead of a ladder” – you change the plan (principle 2).
Nigerian example: A group of students in Ibadan preparing for a quiz – they don’t study everything, they focus on what’s important (simplicity). Every Friday they review what worked and what didn’t (reflect and adjust).
Traditional way (Waterfall) is like building a bridge: you plan everything, then build, then test at the very end. Changes are very expensive.
Agile is like baking a cake: you taste the batter, add sugar, bake a little, then add icing, taste again … you keep adjusting until it’s perfect.
| Waterfall | Agile |
|---|---|
| Big plan upfront | Plan a little, then adapt |
| Changes are difficult | Changes are welcome |
| Testing at the end | Testing all the time |
| One big delivery | Many small deliveries |
| Customer sees product only at the end | Customer sees product early and often |
Waterfall timeline:
[ Research ] → [ Design ] → [ Build ] → [ Test ] → [ Launch ]
(if something is wrong, go back to start – painful!)
Agile timeline:
[Plan] → [Build] → [Test] → [Show] → [Learn] → [Plan again] → ...
(each cycle is short, and you improve each time)
An Agile team is like a football team. Everyone has a role, but they all work together to score goals.
School example: For a class project – the Product Owner is the student who decides the topic, the Scrum Master is the student who keeps everyone organised, and the team does the research and presentation.
Artifacts are just tools or documents that help us stay on track.
Product Backlog (ordered list)
-----------------------------
1. Login screen (most important)
2. Profile picture upload
3. Friend request button
4. Chat feature
...
Sprint Backlog (for this 2-week Sprint)
-----------------------------
- Login screen
- Profile picture upload (partially)
Agile teams hold regular meetings (events) to stay in sync.
Sprint cycle (usually 1–4 weeks):
[ Planning ] → [ Daily Stand-ups (every day) ] → [ Build ] → [ Review ] → [ Retrospective ] → then back to Planning
Nigeria is a country full of energy, creativity, and change. Agile fits perfectly because:
Example: A fintech startup in Lagos builds a mobile money app. They release a simple version that allows transfers. They listen to users, then add bill payments, then add savings. They deliver value early and keep improving.
You already use Agile thinking in your daily life without realising it!
Agile Feedback Loop
┌───────────────────────────────┐
│ Plan (what to do) │
│ ↓ │
│ Do (build a small piece) │
│ ↓ │
│ Check (show to customer) │
│ ↓ │
│ Act (improve based on feedback)│
└───────────────────────────────┘
(repeat many times)
Great job! You have learned the heart of Agile:
Remember: Agile is not just a method, it’s a way of thinking that helps you build awesome things with others.
Match the term on the left with its correct description.
| Term | Description |
|---|---|
| 1. Product Owner | A. List of work to be done, ordered by importance |
| 2. Sprint | B. Short meeting every day to sync |
| 3. Backlog | C. Person who represents the customer |
| 4. Stand-up | D. Fixed period (1-4 weeks) to complete work |
(Answers: 1-C, 2-D, 3-A, 4-B)
Scenario: You are organising a school sports day. You have 2 months to plan. The principal says they want a fun day, but they are not sure about the activities.
Question: How would you use Agile to plan the sports day? Describe the steps you would take.
In groups of 3–4, act out a Daily Stand-up meeting. One person is the Product Owner, one is the Scrum Master, and the others are the team. Each team member says: what they did yesterday, what they will do today, and any blockers. The Scrum Master helps remove blockers.
Write down a personal goal (e.g., “learn to cook jollof rice”). Break it into 5 small steps. For each step, write how you will check if you are doing it well.
Create a simple “Product Backlog” for a project of your choice (e.g., a mobile app for school news). List at least 10 items, ordered from most important to least important. Use a table to show priority and description.
Over the next week, use the Agile mindset in your daily routine. Pick a task (like doing homework). Each day, plan a small part, do it, review it, and adjust. Write a short report about what you learned.
In the next module, we will dive deeper into Agile frameworks – especially Scrum and Kanban. You will learn how to run a Sprint, manage a backlog, and visualise your work. Start thinking about a project you would like to manage using Agile – it could be a school event, a hobby, or even planning a trip!
You have completed Module 1 – well done!
“Two powerful ways to put Agile into action.”
In Module 1, we learned the mindset and principles of Agile. Now it’s time to see how we actually do Agile. Think of Agile like a sport – the mindset is the spirit of the game, but you need rules and positions to play. That’s what frameworks give us.
In this module, we will explore two of the most popular Agile frameworks: Scrum and Kanban. We will learn their roles, events, boards, and how they help teams deliver value. We’ll use simple stories, Nigerian examples, and fun analogies so that even a 10-year-old can understand. Let’s jump in!
Imagine a busy kitchen in a big restaurant in Abuja. There are many chefs, and they all want to cook delicious meals for customers. But if everyone just does whatever they want, there will be chaos – some dishes will be burnt, others will be late.
So the head chef introduces two ways to organise the kitchen:
Both methods help the kitchen run smoothly. In this module, we’ll learn both so you can choose the best one for your project!
Definition: A framework is a set of rules, roles, and practices that help you follow Agile principles.
Why important: A framework gives you a clear path. Without it, Agile can be too vague.
Simple explanation: Think of a framework like a recipe. The Agile mindset is the idea of cooking tasty food, but the recipe tells you exactly what ingredients to mix and in what order.
Real-life example: A school club that meets every week – they have a president, a secretary, and an agenda. That’s a framework!
Nigerian example: A traditional “ajo” savings group – they have rules for contributions, collection, and sharing. That’s a framework.
Agile Mindset (the "why")
|
V
Framework (the "how")
/ \
Scrum Kanban
Definition: Scrum is an Agile framework that uses fixed-length cycles called Sprints (usually 2–4 weeks) to deliver working product.
Why important: Scrum is the most popular Agile framework – many companies use it.
Simple explanation: Imagine you are making a comic book. With Scrum, you plan to draw 5 pages every 2 weeks. At the end of 2 weeks, you show those pages to your fans, get feedback, and plan the next 5 pages.
Real-life example: A team building a mobile app releases a new feature every Sprint.
School example: Every Friday, you present one chapter of your project to the class.
Home example: Every weekend, you clean one room of the house and show your parents.
Nigerian example: A small business in Kano that makes handmade soap – they produce a batch every week, test it on customers, and improve the recipe.
Scrum cycle:
Sprint Planning → Daily Stand-ups → Build → Sprint Review → Retrospective → repeat
Scrum has three key roles:
Analogies:
Scrum has 4 main events:
Sprint timeline (2 weeks):
Day 1: Sprint Planning
Days 2–11: Daily Stand-ups + building
Day 12: Sprint Review & Retrospective
Artifacts are the “things” we use in Scrum:
Product Backlog (ordered)
-------------------------
1. User login (high priority)
2. Profile page
3. Search bar
...
Sprint Backlog (for Sprint 1)
-----------------------------
- User login (design + code + test)
- Profile page (design only)
Definition: Kanban is an Agile framework that uses a visual board to manage work. Work flows through columns like “To Do”, “In Progress”, “Done”.
Why important: Kanban is simple and flexible. It helps teams see bottlenecks and manage capacity.
Simple explanation: Imagine you have a whiteboard with sticky notes. Each note is a task. You move the notes from left to right as you work on them. You limit how many notes can be in each column so you don’t get stuck.
Real-life example: A hospital uses Kanban to track patients: “Waiting”, “With Doctor”, “Tests”, “Discharged”.
School example: A teacher uses a Kanban board to track homework: “Not Started”, “Working”, “Needs Review”, “Finished”.
Nigerian example: A printing press in Enugu uses a Kanban board to track jobs: “Order Received”, “Designing”, “Printing”, “Quality Check”, “Delivered”.
Kanban board (simple)
┌────────────┬────────────┬────────────┐
│ To Do │ Doing │ Done │
│ │ (WIP: 3) │ │
│ Task 1 │ Task 4 │ Task 7 │
│ Task 2 │ Task 5 │ Task 8 │
│ Task 3 │ Task 6 │ │
└────────────┴────────────┴────────────┘
Definition: WIP stands for Work In Progress. A WIP limit is the maximum number of tasks you can have in a column at one time.
Why important: WIP limits prevent overload. When you have too many tasks in progress, nothing gets finished quickly.
Simple explanation: If you try to juggle 5 balls, you will drop them all. But if you juggle 3 balls, you can do it well. WIP limits are like that.
Real-life example: A bakery bakes only 2 types of bread at a time so they don’t burn anything.
Home example: You do only one homework subject at a time instead of mixing them.
| Feature | Scrum | Kanban |
|---|---|---|
| Cadence | Fixed Sprints (e.g., 2 weeks) | Continuous flow (no fixed cycles) |
| Roles | PO, SM, Team | No fixed roles – everyone collaborates |
| Planning | At Sprint start | Continuous – reprioritise anytime |
| Change | Changes can happen between Sprints | Changes can happen at any time |
| WIP limits | Not mandatory | Mandatory (core rule) |
| Best for | Projects with clear priorities, teams that need structure | Support teams, maintenance, or unpredictable work |
Nigerian example: A software startup building a new app might use Scrum. A customer support team handling daily requests might use Kanban.
Some teams mix both frameworks. They use Scrum’s structure (Sprints, roles) but add Kanban’s visual board and WIP limits. This is called Scrumban.
Example: A team uses 2-week Sprints, but they have a Kanban board inside the Sprint to visualise their tasks and limit how many tasks are “In Progress”.
In Nigeria, many small businesses use Kanban informally. A tailor in Aba has a notebook with columns: “Orders”, “Cutting”, “Sewing”, “Finishing”, “Delivered”. They limit the number of orders they start cutting so they don’t get overwhelmed.
A food vendor in Lagos uses a whiteboard to track orders: “Received”, “Cooking”, “Packing”, “Delivered”. This helps them serve customers faster.
In Lagos, Abuja, and Port Harcourt, many tech hubs (like CcHub, Andela, and Co-Creation Hub) use Scrum and Kanban. They train young Nigerians to become Scrum Masters and Product Owners. Agile is helping Nigeria build world-class software and services.
Scrum vs Kanban Flow
Scrum (Sprint-based):
[Sprint 1] → [Sprint 2] → [Sprint 3] → ...
(fixed length, with reviews after each)
Kanban (continuous):
Backlog → To Do → Doing → Done (flow, no fixed cycles)
Excellent work! You have learned two powerful Agile frameworks:
Remember: the best framework is the one that helps your team deliver value effectively. Don’t be afraid to adapt!
Match the framework term with its description.
| Term | Description |
|---|---|
| 1. Sprint | A. Visual board with columns and WIP limits |
| 2. Kanban | B. Fixed period of work (1–4 weeks) |
| 3. Product Owner | C. Coach who removes blockers |
| 4. Scrum Master | D. Represents the customer and prioritises |
(Answers: 1-B, 2-A, 3-D, 4-C)
Scenario: You run a small printing shop in Ibadan. You have 5 employees and many orders. Orders often get delayed because people start too many jobs at once.
Question: Which framework would you recommend to improve the workflow? How would you set it up?
In groups of 4, create a Kanban board for a school event (like a cultural day). Draw the board on paper with columns. Add WIP limits. Then simulate moving tasks across the board.
Set up a personal Kanban board for your week. Use a piece of paper or a digital tool. Track your homework, chores, and personal tasks. Limit your “Doing” column to 3 items. Review at the end of the week.
Plan a 2-week Scrum project for a small app (e.g., a “Daily Motivation” app). Write a Product Backlog with 10 items, create a Sprint Backlog for the first Sprint, and list the roles (PO, SM, Team) with names.
For one week, observe a process in your home or school (e.g., doing laundry, preparing meals, or homework). Draw a Kanban board for that process. Identify bottlenecks and suggest improvements.
In Module 3, we will dive into Agile Planning and Estimation. You will learn how to estimate effort, prioritise tasks, and create release plans. We’ll explore story points, planning poker, and velocity. Start thinking about a project you’d like to plan – it could be a school event, a small app, or even a family trip!
You have completed Module 2 – fantastic!
“Knowing how much work you can do, and planning smartly.”
In Modules 1 and 2, we learned the Agile mindset and the two most popular frameworks – Scrum and Kanban. But how do we know how long a project will take? How do we decide which tasks are most important? That’s what planning and estimation are all about.
Imagine you are planning a big trip. You need to know how much money to save, how many days to take, and what to pack. Agile planning is like that – but for projects. We break big goals into smaller pieces, guess how much effort each piece needs, and then adjust as we go.
In this module, we will learn story points, velocity, planning poker, release planning, and prioritisation techniques. We’ll use simple words, fun examples, and Nigerian stories to make everything clear. Let’s dive in!
Your school is organising a big fair. There are 10 stalls, games, and food. The principal asks you: “How long will it take to set everything up?”
You have never done this before. But you have a team of 10 students. Instead of guessing wildly, you break the work into small tasks: setting up a stall takes 1 hour, decorating takes 30 minutes, and practising games takes 2 hours. You count the tasks and add them up. You also know that some tasks are bigger than others – the “food stall” is huge, while the “balloon stand” is small.
You assign points to each task based on size. Then you track how many points your team can complete per day. That is exactly how Agile estimation works – it’s like planning a school fair, but for software or any project!
Definition: Estimation is a way to guess how much effort a task will need.
Why important: Estimates help us plan, set expectations, and decide what to work on next.
Simple explanation: When you pack for a trip, you guess how many clothes you need. That’s an estimate. It’s not perfect, but it helps.
Real-life example: A chef estimates how many plates of food to cook for a party.
School example: A teacher estimates how long it will take for students to finish a test.
Home example: You estimate how long it will take to clean your room.
Nigerian example: A tailor in Kano estimates how much fabric is needed for a customer’s outfit.
Estimation helps us:
- Plan better
- Set realistic goals
- Avoid being too busy or too idle
Traditional way: Estimate in hours or days. But humans are bad at estimating time – we are often wrong.
Agile way: Estimate in relative size. We compare tasks to each other. For example, Task A is twice as big as Task B.
Why relative is better: It’s easier to say “this is bigger than that” than to say “this takes exactly 5 hours”.
| Traditional (hours) | Agile (relative) |
|---|---|
| “This takes 10 hours.” | “This is a 3-point task.” |
| “That takes 6 hours.” | “That is a 2-point task.” |
| Often wrong, hard to compare. | Easier to compare, more consistent. |
Definition: A story point is a number that represents the size of a task. It includes effort, complexity, and uncertainty.
Why important: Story points help teams estimate consistently.
Simple explanation: Think of story points like “T-shirt sizes” – XS, S, M, L, XL. We give each task a size instead of a time.
Example scale: 1 = very small, 2 = small, 3 = medium, 5 = large, 8 = very large, 13 = huge (we use numbers like Fibonacci).
Nigerian example: A tailor might estimate fabric needs: small = 2 yards, medium = 4 yards, large = 6 yards. That’s relative.
Story point scale (Fibonacci-like):
1, 2, 3, 5, 8, 13, 21
(each number is roughly the sum of the previous two)
Definition: Velocity is the number of story points your team completes in one Sprint.
Why important: Velocity helps predict how much work you can do in future Sprints.
Simple explanation: If you complete 15 story points in Sprint 1, your velocity is 15. In Sprint 2, you can plan around 15 points.
Real-life example: A moving company knows they can move 3 houses per week – that’s their “velocity”.
School example: If you read 2 chapters per day, your velocity is 2 chapters/day.
Definition: Planning Poker is a game where the team estimates tasks together using cards with numbers.
Why important: It involves everyone and leads to better estimates through discussion.
How to play:
Nigerian example: A team building a mobile app for a bank in Lagos uses Planning Poker to estimate features like “transfer money” and “check balance”.
Planning Poker cards:
[ 0 ] [ 1 ] [ 2 ] [ 3 ] [ 5 ] [ 8 ] [ 13 ] [ 21 ] [?] [∞]
(Each team member holds one card face down)
Definition: Prioritisation means ordering tasks from most important to least important.
Why important: We can’t do everything at once. We need to focus on what delivers the most value.
Simple explanation: When you pack for a trip, you pack your passport first, then clothes, then snacks. That’s prioritisation.
Technique – MoSCoW:
Nigerian example: A food delivery app in Abuja: “Must have” = menu and ordering, “Should have” = ratings, “Could have” = loyalty points.
Definition: Release planning is a long-term plan that shows when features will be delivered over several Sprints.
Why important: It helps stakeholders know when to expect new features.
Simple explanation: If you are building a house, release planning tells you when each room will be finished.
Steps:
Release Plan Example:
Total Product Backlog points = 120
Velocity = 20 points per Sprint
Number of Sprints = 120 / 20 = 6 Sprints
If each Sprint is 2 weeks, release in 12 weeks.
Definition: Story slicing is breaking a large task into smaller, more manageable pieces.
Why important: Small tasks are easier to estimate, complete, and test.
Simple explanation: Instead of “build a whole website”, slice it into “homepage”, “contact page”, “about page”.
Nigerian example: A caterer doesn’t cook all meals at once – they cook jollof rice, then chicken, then salad.
Some teams use T-shirt sizes instead of numbers: XS, S, M, L, XL.
This is a fun way to estimate, especially for beginners.
| T-shirt size | Points (approx.) | Example |
|---|---|---|
| XS | 1 | Typo fix |
| S | 2 | Add a button |
| M | 5 | Create a login page |
| L | 8 | Add payment feature |
| XL | 13 | Build a whole reporting system |
Definition: Affinity estimation is a technique where you group tasks by size without assigning exact numbers.
Why important: It’s fast and helps when you have many items to estimate.
How to do it: Put tasks on sticky notes. Move them into groups: “small”, “medium”, “large”. Then assign points to each group.
As you learn more, your estimates might change. That’s okay – Agile welcomes change.
If a task turns out to be bigger than you thought, you can re-estimate it.
Example: You thought “add search bar” was a 2-point task, but you discover it needs a lot of testing – you change it to 5 points.
Estimation Flow:
Product Backlog → Estimate each item → Calculate total points
↓
Velocity (points/Sprint) → Release Planning → Delivery date
Amazing work! You have mastered the art of Agile planning and estimation:
Remember: estimates are guides, not promises. Keep learning and improving!
Match the term with its correct definition.
| Term | Definition |
|---|---|
| 1. Story point | A. A number that represents the size of a task |
| 2. Velocity | B. A game where the team estimates together |
| 3. Planning Poker | C. Points completed per Sprint |
| 4. MoSCoW | D. A prioritisation technique |
(Answers: 1-A, 2-C, 3-B, 4-D)
Scenario: You are leading a team of 5 students to build a school website. The Product Backlog has 20 items. Your team’s velocity is 10 points per Sprint. Each Sprint is 2 weeks.
Question: How many Sprints will you need to complete all 20 items if the total points are 40? How long will that take?
In groups of 4, play a round of Planning Poker. Use a list of 5 tasks (e.g., “write a letter”, “draw a picture”, “build a small tower”). Each person uses cards (1, 2, 3, 5, 8). Discuss and reach consensus.
Take a project you are working on (e.g., a school project, a hobby). Write down 5 tasks. Estimate each using T-shirt sizes (XS, S, M, L, XL). Then convert them to story points (e.g., XS=1, S=2, M=5, L=8, XL=13).
Create a release plan for a small app (e.g., a “study timer” app). Write a Product Backlog with 10 items. Estimate each in story points. Assume a velocity of 8 points per Sprint. Plan how many Sprints you need.
Over the next week, track your personal velocity for a chosen activity (e.g., reading pages per day, solving math problems). Calculate your average and use it to plan the following week.
In Module 4, we will explore Agile Metrics and Continuous Improvement. You will learn how to measure progress, track team health, and use data to get better. We’ll cover burndown charts, cumulative flow diagrams, and how to run effective retrospectives. Start thinking about how you might measure your own improvement – it could be in school, sports, or a hobby!
You have completed Module 3 – keep going!
“What gets measured gets improved.” – Peter Drucker
In the first three modules, we learned the Agile mindset, frameworks like Scrum and Kanban, and how to plan and estimate. But how do we know if we are actually getting better? How do we spot problems early?
That’s where metrics come in. Metrics are like the dashboard of a car – they tell you your speed, fuel level, and if something is wrong. In Agile, we use metrics to track progress, find bottlenecks, and improve continuously.
We will also talk about continuous improvement – the heart of Agile. It’s the idea that we should always look for ways to do better, little by little. We’ll use simple language, stories, and Nigerian examples to make everything clear. Let’s go!
Imagine you are a football coach in Abuja. Your team plays every week, but you keep losing. You don’t know why.
One day, you start recording metrics: how many passes each player makes, how many shots on goal, how many fouls. After a few games, you see that your striker makes very few shots. You also see that the defense gives away many fouls.
Now you know what to fix. You practice shooting with the striker and teach the defense to tackle better. Your team improves!
That’s exactly what Agile metrics do – they give you information so you can improve. Let’s learn how.
Definition: Metrics are numbers or data that tell you how your project is going.
Why important: Without metrics, you are guessing. Metrics help you make smart decisions.
Simple explanation: Think of metrics like the scoreboard in a game. It tells you who is winning and where you need to improve.
Real-life example: A bakery tracks how many loaves of bread they sell each day – that’s a metric.
School example: Your test scores are metrics – they show how well you are learning.
Home example: You track how many chores you complete each week – that’s a metric.
Nigerian example: A small shop in Onitsha tracks how many customers come in each hour – to know when to add more staff.
Metrics help you:
- See progress
- Spot problems early
- Make decisions based on data, not feelings
Definition: A Burndown Chart shows how much work is left over time. It goes down (burns down) as you complete tasks.
Why important: It helps you see if you are on track to finish your Sprint on time.
Simple explanation: Imagine you have 10 chocolates. Each day you eat some. A burndown chart shows the number of chocolates left each day – it goes down!
Real-life example: A moving company tracks how many boxes are left to pack each day.
School example: You have 5 chapters to read in 5 days – each day you mark how many chapters are left.
Nigerian example: A tailor tracks how many dresses are left to sew each day before a wedding.
Burndown Chart (Sprint of 10 days)
Day 1: 30 points left
Day 2: 28 points left
Day 3: 25 points left
...
Day 10: 0 points left (Sprint done!)
(the line goes down like a slide)
Definition: A CFD shows the amount of work in different states (To Do, Doing, Done) over time.
Why important: It helps you see bottlenecks – where work is piling up.
Simple explanation: Imagine a pipe. If water gets stuck, it’s a bottleneck. A CFD shows you where the clog is.
Real-life example: A car wash tracks how many cars are waiting, being washed, and finished.
Nigerian example: A printing press tracks jobs at each stage: “Ordered”, “Printing”, “Cutting”, “Delivered”.
Cumulative Flow Diagram (simplified)
Time → | To Do | Doing | Done |
Day 1 | 10 | 3 | 2 |
Day 2 | 8 | 4 | 5 |
Day 3 | 5 | 2 | 8 |
(If “Doing” grows wide, you have a bottleneck)
Definitions:
Why important: Shorter times mean faster delivery and happier customers.
Simple explanation: At a restaurant, Lead Time = time from ordering to eating. Cycle Time = time from cooking to serving.
Real-life example: Online shopping – lead time is from order to delivery; cycle time is from packing to shipping.
Nigerian example: A generator repair shop – lead time is from when you bring it in to when you pick it up; cycle time is from when they start fixing it to when it’s fixed.
We learned about velocity in Module 3. It’s the average number of story points completed per Sprint.
Why important: Velocity helps you forecast and plan future Sprints.
Simple explanation: If you run 2 km per day on average, you can predict how long it will take to run 10 km.
Remember: Velocity is not a performance target – it’s a planning tool.
Definition: Throughput is the number of tasks completed per unit of time (e.g., per week).
Why important: It shows how productive your team is, regardless of task size.
Simple explanation: If you send 10 emails per day, your throughput is 10 emails/day.
Nigerian example: A call centre in Lagos tracks how many customer calls they handle per hour – that’s throughput.
We covered WIP limits in Module 2. WIP is the number of tasks you are currently working on.
Tracking WIP helps you see if your team is overloaded. High WIP often means slower delivery.
Simple explanation: If you try to juggle 5 balls, you drop them. WIP limit = 3 balls – you juggle better.
Definition: The Sprint Retrospective is a meeting at the end of each Sprint where the team reflects and plans improvements.
Why important: This is where continuous improvement actually happens.
Simple explanation: It’s like a post-game review for a football team – you discuss what went well, what didn’t, and what to change.
Structure:
Nigerian example: A group of students after a test – they discuss which topics were hard and plan extra study.
Retrospective format:
[ Start ] → [ Gather data ] → [ Insights ] → [ Decide actions ] → [ End ]
(keep it positive and action-oriented)
Definition: Continuous improvement means always looking for small ways to get better.
Why important: Small improvements add up to big changes over time.
Simple explanation: If you improve 1% every day, you’ll be 37 times better after a year!
Real-life example: A basketball player practices free throws for 10 minutes extra each day – improves over time.
Nigerian example: A shopkeeper rearranges the shelf to make it easier for customers – a small improvement that boosts sales.
Let’s put it all together. Your team sees that the Burndown Chart shows work is not decreasing fast enough. You look at the CFD and see that “Testing” has a huge backlog. You realise testing is the bottleneck.
You decide to add more testers or automate some tests. Next Sprint, the Burndown looks better. That’s using metrics to improve.
Definition: Vanity metrics look good but don’t help you make decisions.
Example: “We wrote 100 pages of documentation” – but nobody reads it. That’s a vanity metric.
Better: “We completed 20 story points” – that actually matters.
Burndown Chart (simplified)
Work left
|
30 | X
25 | X
20 | X
15 | X
10 | X
5 | X
0 |_____________X___
Day1 Day2 Day3 Day4 Day5
CFD (simplified)
| To Do | Doing | Done |
| 10 | 2 | 3 | Day1
| 8 | 3 | 6 | Day2
| 5 | 3 | 10 | Day3
(Doing stays flat – may be a bottleneck)
Brilliant work! You have learned how to measure and improve in Agile:
Remember: the goal is not to collect data, but to use data to deliver more value and have a happier team.
Match the metric with its description.
| Metric | Description |
|---|---|
| 1. Burndown Chart | A. Number of items completed per time |
| 2. Velocity | B. Work in different states over time |
| 3. Throughput | C. Points per Sprint |
| 4. CFD | D. Work left over time |
(Answers: 1-D, 2-C, 3-A, 4-B)
Scenario: Your team’s Burndown Chart shows that at the end of Day 5 of a 10-day Sprint, you still have 60% of the work left. You look at the CFD and see that “Testing” has a huge backlog.
Question: What should you do? What metric would you use to track your improvement?
In groups of 4, simulate a Sprint Retrospective. Each person shares one thing that went well, one thing that didn’t, and one improvement they suggest. Together, decide on two actions to try next Sprint.
For one week, track a simple metric for a personal goal (e.g., pages read per day, exercise time). At the end of the week, reflect on what you learned and what you could improve.
Create a Burndown Chart for a 5-day school project. Estimate the total work (e.g., 20 points). Each day, record how many points you have completed. Plot the chart and analyse if you are on track.
In your next team meeting (or family meeting), run a mini-retrospective. Ask: “What went well?” “What didn’t?” “What will we change?” Document the actions and follow up.
In Module 5, we will explore Advanced Agile Topics – including scaling Agile to large teams, distributed teams, and combining Agile with other practices like DevOps. You’ll also learn about the role of the Agile coach and how to lead change in an organisation.
Think about a large project (like building a whole school website) – how would you apply Agile with many teams? We’ll answer that next!
You have completed Module 4 – incredible progress!
“Agile is not just for small teams – it can transform entire organisations.”
Congratulations! You have learned the Agile mindset, frameworks, planning, estimation, and metrics. Now it’s time to see how Agile works in the real world – with big teams, remote workers, and entire companies.
In this final module, we will explore scaling Agile – how to use Agile when you have many teams working on the same product. We’ll also talk about Agile leadership – how to be a great servant leader, and how to lead change in an organisation.
We’ll use stories, examples from Nigeria, and simple language to make these advanced topics easy to understand. Let’s get started!
Imagine you are in a huge market in Lagos – like Balogun Market. There are hundreds of shops selling different things. Each shop works well on its own, but how do they all work together to make the market successful?
Now imagine that the market wants to become an online shopping platform. This is a massive project. One Agile team cannot do it alone – you need many teams: a team for the website, a team for payments, a team for delivery, and a team for customer service.
How do you coordinate all these teams? That’s what scaling Agile is all about. It’s like conducting an orchestra – each section plays its own part, but they all follow the same sheet music.
In this module, we learn how to conduct the orchestra!
Definition: Scaling Agile means using Agile methods for large projects with many teams.
Why important: Small teams can use Scrum or Kanban easily. But when you have 50 or 100 people, you need more coordination.
Simple explanation: Think of a small boat – one person can row it. A big ship needs a captain, a crew, and a system to steer it. That’s scaling.
Real-life example: Building a new airport – you have teams for construction, electrical, plumbing, and landscaping.
Nigerian example: A Nigerian bank building a new mobile app – they have a team for Android, iOS, backend, and security.
Definition: SAFe is the most popular framework for scaling Agile. It has levels: Team, Program, Large Solution, and Portfolio.
Why important: SAFe gives a clear structure for large organisations.
Simple explanation: SAFe is like a school system – you have classrooms (teams), grades (programs), and a principal (portfolio).
Key levels:
SAFe Levels (simplified)
┌─────────────────────────────────┐
│ Portfolio (strategy & funding) │
├─────────────────────────────────┤
│ Program (ART – many teams) │
├─────────────────────────────────┤
│ Team (Scrum / Kanban) │
└─────────────────────────────────┘
Definition: An ART is a group of teams (usually 5–12) that work together to deliver a product or solution.
Why important: ART helps coordinate many teams so they don’t step on each other’s toes.
Simple explanation: Think of a train – the ART is the train, and each team is a carriage. They all move together.
Nigerian example: A telecom company in Lagos has an ART for their mobile money product – with teams for USSD, app, and backend.
Definition: A servant leader puts the team first – they help the team succeed.
Why important: Agile teams need support, not control.
Simple explanation: Instead of being a “boss” who tells people what to do, a servant leader asks: “How can I help you?”
Real-life example: A football coach who brings water and gives encouragement – not just shouting orders.
School example: A teacher who walks around the classroom helping students who are stuck.
Nigerian example: A “chairman” of a local community who listens to people’s problems and finds solutions.
Definition: An Agile Coach helps teams and organisations adopt Agile practices.
Why important: Change is hard – a coach guides people through it.
Simple explanation: An Agile Coach is like a personal trainer for your team – they help you get fit in Agile.
Responsibilities:
Definition: Distributed teams work in different locations – sometimes in different cities or countries.
Why important: Many companies now have remote teams – especially after COVID-19.
Challenges:
Solutions:
Nigerian example: A Nigerian fintech has developers in Lagos, Abuja, and London – they use video calls and online boards to stay connected.
Dr. John Kotter created an 8-step model for leading change. Here’s the simple version:
Nigerian example: A company wants to go Agile – they start with one team (quick win), show success, then expand to other teams.
An Agile culture is one where people:
Nigerian example: In some Nigerian companies, the culture is top-down. Agile culture encourages everyone to speak up – even junior staff.
Agile is not just for private companies. Some Nigerian government agencies and NGOs are starting to use Agile to deliver services faster.
Example: A state government uses Agile to build a portal for citizens to pay taxes – they release a simple version, get feedback, and improve.
Definition: DevOps is a way to combine development (Dev) and operations (Ops) to deliver software faster and more reliably.
Why important: Agile focuses on building features; DevOps focuses on releasing them smoothly.
Simple explanation: Agile is like cooking, and DevOps is like plating and serving the food quickly.
Nigerian example: A Nigerian e-commerce company uses Agile to build new features and DevOps to deploy them every day.
After learning all this, you might want to become:
You can also get certified! The PMI-ACP is a great start. In Nigeria, many companies look for Agile professionals.
Scaling Agile Journey:
Team 1 (pilot) → Team 2 → Team 3 → Program → Portfolio
(start small, then expand)
Change Model (Kotter simplified):
Urgency → Team → Vision → Communicate → Remove Obstacles → Quick Wins → Keep Going → Make Stick
| Feature | Small Team | Scaled (Large) |
|---|---|---|
| Number of teams | 1–2 | 5–100+ |
| Coordination | Daily Stand-ups | ART sync, Scrum of Scrums |
| Roles | PO, SM, Team | Plus Release Train Engineer, Solution Architect |
| Planning | Sprint Planning | PI Planning (Program Increment) |
Congratulations on completing this journey! You have learned:
You now have the knowledge to apply Agile in any situation – from a small school project to a large company. Keep learning, keep improving, and keep the Agile mindset alive!
Match the scaling term with its description.
| Term | Description |
|---|---|
| 1. SAFe | A. A group of teams working together |
| 2. ART | B. A leader who serves the team |
| 3. Servant Leader | C. A framework for scaling Agile |
| 4. Agile Coach | D. A guide for Agile adoption |
(Answers: 1-C, 2-A, 3-B, 4-D)
Scenario: Your company has 10 teams working on a single product. They are not coordinating well – features overlap, and releases are delayed. You are asked to help.
Question: What steps would you take to scale Agile in this company? Use the concepts from this module.
In groups of 5, simulate a Program Increment (PI) Planning session. Each group represents a team. Together, plan a release for a large product (e.g., a school management system).
Reflect on a time when you had to work with many people on a project. What challenges did you face? How could Agile scaling have helped?
Design a scaled Agile structure for a fictional Nigerian company with 50 employees building a new product. Include team structures, roles, and a coordination plan.
Interview a professional who works in a large organisation (or research online). Find out how they coordinate multiple teams. Write a short report comparing their approach to Agile scaling.
You have now completed the full Certified Agile Practitioner course. You have learned:
You are now ready to take the PMI-ACP certification exam or apply Agile in your projects. Keep learning, keep practicing, and never stop improving!
🎉 You are an Agile Practitioner! 🎉
Thank you for being part of this journey.
“Your certification journey – turning knowledge into a career.”
Congratulations! You have completed all five modules of this course. You now understand the Agile mindset, frameworks, planning, metrics, and even how to scale Agile in large organisations.
But what’s next? In this final module, we’ll help you prepare for the PMI-ACP certification exam and explore the career opportunities that Agile offers. We’ll give you tips, practice questions, and guidance on how to continue your learning journey.
Think of this module as your “launchpad” – it will give you the confidence to take the exam and start your Agile career. Let’s go!
Imagine you have been training for a marathon for months. You’ve run many miles, you know the route, and you have the right shoes. On race day, you feel nervous but also excited. You know you are prepared.
The PMI-ACP exam is like that marathon. You’ve done the training (the five modules). Now it’s time to put your knowledge to the test. But don’t worry – just like a marathon, you can pace yourself, use strategies, and cross the finish line with confidence.
In this module, we’ll help you prepare so that exam day feels like just another training run – except this time, you get a certification at the end!
Definition: The PMI-ACP (Agile Certified Practitioner) is a certification from the Project Management Institute (PMI) that validates your Agile knowledge.
Why important: It is one of the most recognised Agile certifications in the world.
Exam details:
Nigerian example: Many Nigerian professionals take the PMI-ACP to advance their careers in banks, tech hubs, and multinational companies.
The exam covers 7 domains (areas). We’ve covered all of them in this course!
Illustration:
PMI-ACP Domains (percentage of questions)
┌──────────────────────────────────────────────────────────────┐
│ 1. Mindset ████████░░░░ 16% │
│ 2. Value Delivery ████████░░░░ 16% │
│ 3. Stakeholder ████████░░░░ 16% │
│ 4. Team Performance████████░░░░ 16% │
│ 5. Adaptive Plan ███████░░░░░ 12% │
│ 6. Problem Solve ██████░░░░░░ 10% │
│ 7. Improvement ██████░░░░░░ 10% │
└──────────────────────────────────────────────────────────────┘
To apply for the PMI-ACP, you need:
Simple explanation: You need to have some experience, plus the training hours from this course.
Nigerian example: Many Nigerian candidates form WhatsApp study groups to share tips.
Exam time management:
120 questions / 180 minutes = 1.5 minutes per question
- Answer easy ones first
- Flag hard ones
- Use the last 10 minutes to review flagged questions
Question 1: The Agile Manifesto values “working software” over comprehensive documentation. Which of the following best reflects this?
Answer: B – working product is more valuable than extensive documentation.
Question 2: Which Scrum event is used to inspect and adapt the process?
Answer: D – the Retrospective is where the team improves its process.
Question 3: A Product Owner wants to add a new feature mid-Sprint. What should the team do?
Answer: B – changes during a Sprint are discouraged; add it to the backlog for the next Sprint.
Question 4: Which metric shows work left over time in a Sprint?
Answer: B – Burndown Chart.
After certification, you can pursue many roles:
Nigerian example: In Nigeria, Scrum Masters and Product Owners are in high demand, especially in fintech and banking.
Why important: Networking helps you learn, find mentors, and discover job opportunities.
Agile is always evolving. To stay current:
Now it’s time to create your plan:
Your Journey to Certification
┌────────────────────────────────────────────────────────────────────┐
│ 1. Learn (5 modules) → 2. Practice (mock exams) → 3. Apply │
│ ↓ ↓ ↓ │
│ 4. Study (review) → 5. Take Exam → 6. Celebrate! 🎉 │
└────────────────────────────────────────────────────────────────────┘
| Method | Pros | Cons |
|---|---|---|
| Self-Study | Flexible, low cost | Need self-discipline |
| Bootcamp | Structured, immersive, group support | Costly, fixed schedule |
| Combination | Best of both | Requires more effort |
You’ve made it! This module gave you the tools to succeed:
You now have everything you need to become a certified Agile practitioner. The rest is up to you – but we know you can do it!
Match the career role with its primary responsibility.
| Role | Responsibility |
|---|---|
| 1. Scrum Master | A. Prioritises and manages the backlog |
| 2. Product Owner | B. Helps teams follow Agile |
| 3. Agile Coach | C. Guides Agile adoption at scale |
| 4. Release Train Engineer | D. Coordinates multiple teams in SAFe |
(Answers: 1-B, 2-A, 3-C, 4-D)
Scenario: You have just passed the PMI-ACP exam. You want to find a job as a Scrum Master. Your CV is ready, but you don’t have much experience.
Question: What steps would you take to improve your chances of getting hired? (Think about networking, internships, volunteering, and continuous learning.)
In groups of 4, create a “Study Plan” for the PMI-ACP. Decide how many weeks you need, what resources to use, and how you will track progress. Share your plan with the class.
Create your personal action plan using the template from Lesson 11. Write down your exam date, study schedule, and resources. Commit to it.
Design a “Practice Exam” with 20 questions covering all 7 domains. Write the questions and the correct answers with explanations. Swap with a classmate and take each other’s exams.
Visit the PMI website and review the PMI-ACP application process. Gather your project experience details and start filling out the application. Submit it within the next 2 weeks.
You have now completed all six modules of the Certified Agile Practitioner course. You’ve learned:
You are now fully prepared to take the PMI-ACP exam and start your Agile career. Remember:
🎉 You are an Agile Champion! 🎉
Thank you for your dedication. Go out there and make a difference!
“See Agile in real projects – and practice it yourself!”
You have learned all the theory – now it’s time to see Agile in action. In this module, we will walk through real-world case studies and simulations. You will see how Agile is used in different industries, and you will even get to practice running an Agile project yourself.
Think of this module as a “flight simulator” for Agile. You get to practice without any risk. By the end, you will feel confident to apply Agile in your own projects – whether at school, at home, or in your future career.
Let’s dive into the stories!
There were two teams building a new mobile app for a bank in Lagos.
Team A used the traditional Waterfall method. They spent 6 months writing requirements, then 6 months coding, then 3 months testing. When they launched, the app was already outdated, and users didn’t like the design. They had to start over.
Team B used Agile. They built a simple version in 2 weeks and showed it to customers. They added features every 2 weeks based on feedback. After 6 months, they had a product that customers loved – and they kept improving it.
Team B’s story is the story of Agile in action. In this module, we will explore real examples like this one.
"summary-box">✅ Mini summary: Agile allowed the startup to deliver value early and adapt to user needs.
"summary-box">✅ Mini summary: Kanban worked well for the school because priorities changed often.
"summary-box">✅ Mini summary: SAFe helped coordinate many teams to achieve a big goal.
Now it’s your turn! Let’s simulate a Sprint for a project: “Build a school event website.”
Scenario: You are the Scrum Master. You have 4 team members. The Product Owner wants a simple website with an event schedule, registration, and a photo gallery.
Steps:
Your task: Write down what you would do in each step.
Simulation board:
┌───────────────┬──────────────────┬──────────────────┐
│ Backlog │ Sprint Backlog │ Done │
├───────────────┼──────────────────┼──────────────────┤
│ Homepage │ Homepage │ Registration │
│ Schedule │ Schedule │ (moved to Done) │
│ Registration │ (in progress) │ │
│ Photo gallery │ │ │
│ Contact form │ │ │
└───────────────┴──────────────────┴──────────────────┘
"summary-box">✅ Mini summary: Agile can improve services beyond software – like healthcare.
"summary-box">✅ Mini summary: Agile can transform public services – delivering faster results to citizens.
| Tool | Best for | Popular in Nigeria? |
|---|---|---|
| Jira | Scrum, Kanban, SAFe | Yes, very common |
| Trello | Simple Kanban boards | Yes, used by startups |
| Asana | Task management | Growing |
| Monday.com | Visual project tracking | Used by some companies |
| Physical board | Small teams, co-located | Used in many offices |
Many Nigerian teams now work remotely. Agile helps them stay connected.
You don’t need to wait for a job to use Agile. Start a small project today:
Agile Project Flow
┌────────────────────────────────────────────────────────────┐
│ 1. Idea → 2. Product Backlog → 3. Sprint Planning │
│ ↓ ↓ │
│ 4. Build (Daily Stand-ups) → 5. Sprint Review │
│ ↓ ↓ │
│ 6. Retrospective → 7. Repeat (improved!) │
└────────────────────────────────────────────────────────────┘
| Metric | Waterfall | Agile |
|---|---|---|
| Time to first release | 12+ months | 2-4 weeks |
| Customer involvement | Low | High |
| Ability to change | Difficult | Easy |
| User satisfaction | Often low | High |
| Team morale | Can be low (late changes) | High (visible progress) |
Incredible work! You have seen Agile in action and practiced it yourself:
Agile is not just a course – it’s a way of life. Go out there and build amazing things!
Match the case study with its industry.
| Case Study | Industry |
|---|---|
| 1. Mobile money app | A. Healthcare |
| 2. School management system | B. Fintech |
| 3. Patient check-in | C. Education |
| 4. E-commerce recommendation engine | D. Retail |
(Answers: 1-B, 2-C, 3-A, 4-D)
Scenario: You are leading an Agile team for a new project – a community food bank app. The app will help people find food distribution points and track inventory. Your team has 5 members, and they are all new to Agile.
Question: How would you introduce Agile to the team? What framework would you use? Walk through the first Sprint.
In groups of 5, simulate a complete Sprint for the food bank app. Assign roles: Product Owner, Scrum Master, and 3 Team Members. Conduct Sprint Planning, Daily Stand-ups (simulate 3 days), a Sprint Review, and a Retrospective. Present your results to the class.
Write a short report on a case study from your own experience or from online research. Explain the project, the Agile approach used, and the results. Share what you learned from the case study.
Plan an Agile project for a personal goal (e.g., “Learn to play the guitar” or “Save ₦50,000” or “Read 10 books”). Create a Product Backlog, plan a Sprint, and track your progress for 2 weeks. Document your journey.
Choose a real project at your school, church, or community. Apply Agile to it. Use a Kanban board (physical or digital). Track your progress for one month. Write a reflection on what worked well and what you would improve.
You have completed all seven modules of the Certified Agile Practitioner course. You’ve gone from learning the Agile mindset to applying it in real-life simulations. You are now ready to:
Remember: Agile is not a destination – it’s a journey. Keep learning, keep practicing, and keep improving.
🎉 You are now an Agile Practitioner – go make a difference! 🎉
Thank you for your hard work and dedication.