← Certified Agile Developer Β· Lesson 4 of 11

Module Three

πŸ“– Every lesson in this course is free to read right here, no account needed. Create a free account to track your progress, take the exam, and earn your certificate.
1

Course Outline

Course Outline: Certified Agile Developer

πŸ“˜ Certified Agile Developer

Course Outline – A beginner‑friendly guide to becoming an Agile developer who delivers value faster and better.


πŸ“Œ Course Overview

This course is designed for developers who want to learn the Agile way of working. You will learn what Agile is, how to plan and build software in small chunks, and how to work with a team to deliver value every week. No prior Agile experience needed – just curiosity and a willingness to learn!

Target Audience: Software developers, testers, team leads, and anyone who builds software.

Format: Self‑paced with videos, hands‑on exercises, real‑world projects, and group discussions.

Estimated time: 6–8 hours (depending on practice).


🎯 Learning Objectives

  • Explain the Agile mindset and its core values.
  • Apply Scrum and Kanban frameworks in real projects.
  • Write user stories and break down features.
  • Plan and estimate work using story points and velocity.
  • Run effective sprints and retrospectives.
  • Build a continuous delivery pipeline.
  • Collaborate with product owners and stakeholders.

πŸ“š Modules (10 Lessons)

Module 1 What is Agile?
  • Agile values and principles
  • Agile vs. Waterfall
  • The Agile manifesto
Module 2 Agile Frameworks – Scrum
  • Scrum roles (PO, SM, Team)
  • Sprints and artefacts
  • Scrum events (Planning, Review, Retro)
Module 3 Kanban – Visualising Work
  • Kanban board and WIP limits
  • Flow and lead time
  • Scrum vs. Kanban
Module 4 User Stories & Backlog
  • Writing effective user stories
  • INVEST criteria
  • Backlog refinement and prioritisation
Module 5 Agile Estimation & Planning
  • Story points and planning poker
  • Velocity and capacity planning
  • Release planning
Module 6 Sprint Execution
  • Daily stand‑ups
  • Task breakdown
  • Managing dependencies
Module 7 Continuous Integration & Delivery
  • CI/CD pipeline basics
  • Automated testing
  • Deployment strategies
Module 8 Agile Testing
  • Test-driven development (TDD)
  • Acceptance criteria
  • Exploratory testing
Module 9 Agile Collaboration & Culture
  • Cross‑functional teams
  • Pair programming
  • Feedback and retrospectives
Module 10 Agile Scaling & Beyond
  • Scaling Agile (SAFe, LeSS)
  • Agile metrics
  • Agile for non‑IT teams

πŸ“‹ Detailed Module Breakdown

Module Key Topics Practical Activity
1 – Intro Values, principles, Agile mindset Read the Agile manifesto
2 – Scrum Roles, artefacts, events Run a mock sprint planning
3 – Kanban Board, WIP, flow Create a Kanban board
4 – User Stories Writing, INVEST, backlog Write 5 user stories
5 – Estimation Story points, velocity Play planning poker
6 – Sprint Execution Stand‑ups, tasks, dependencies Simulate a daily stand‑up
7 – CI/CD Pipeline, automation, deployment Set up a simple CI pipeline
8 – Agile Testing TDD, acceptance, exploratory Write a TDD test
9 – Collaboration Cross‑functional, pair programming Pair programming exercise
10 – Scaling SAFe, LeSS, metrics Research a scaling framework

βœ… Assessment & Certification

  • Quizzes: After each module to check understanding.
  • Practical Projects: Build a product backlog and plan a release.
  • Final Capstone: Run a full sprint cycle on a real‑world project.
  • Certificate: Digital β€œCertified Agile Developer” certificate upon completion.

πŸ“– Recommended Resources

  • The Agile Manifesto (agilemanifesto.org)
  • Scrum Guide (scrumguides.org)
  • β€œUser Stories Applied” by Mike Cohn
  • β€œThe Phoenix Project” (DevOps culture)
  • Online: Atlassian Agile Coach, Scrum.org

❓ Frequently Asked Questions (FAQ)

  • Do I need to know programming? Basic coding helps, but this course focuses on the Agile process – you can learn alongside.
  • Is this the same as Scrum Master? No – this is for developers, but the foundation is similar.
  • How long does it take to become Agile? You can start applying Agile immediately – mastery comes with practice.
  • Can I use Agile in non‑software teams? Yes! Agile principles are used in many fields.

πŸ“Œ Course Summary

This course gives you everything you need to become a Certified Agile Developer. You’ll learn the Agile mindset, Scrum and Kanban frameworks, how to write user stories, plan sprints, and deliver working software every iteration. You’ll also gain hands‑on experience with continuous delivery, testing, and team collaboration. By the end, you’ll be ready to join any Agile team and contribute from day one.


πŸš€ Next Steps

Ready to become Agile? Enrol in the course, get started with Module 1, and start your journey to becoming a Certified Agile Developer!

© 2026 – Certified Agile Developer Course | Course Outline

2

Module One

Module 1: Welcome to Agile – Building Better Together

Module One: Welcome to Agile – Building Better Together

Module Introduction

Hello, future Agile developer! πŸ‘‹ Have you ever worked on a big project and felt lost because things kept changing? Or maybe you finished something and it wasn't what people wanted? Agile is a way of working that helps teams build great things step by step, with lots of feedback along the way. It's like building a house one room at a time, and checking with the owner after each room. In this module, we will learn what Agile is, where it comes from, and why it makes teams happier and products better. Let's begin!

Learning Objectives

By the end of this module, you will be able to:

  • Explain what Agile is in your own words.
  • Describe the Agile Manifesto and its 4 values.
  • List the 12 principles of Agile.
  • Understand why Agile is better than the old way of building software.
  • Recognise Agile in everyday life and work.

Warm-up Story: The Great Jollof Rice Project

In a bustling Nigerian village, there was a cooking competition. The judges asked each team to prepare the perfect Jollof rice. Team A planned everything in secret. They bought ingredients, cooked for hours, and presented a huge pot. The judges tasted it – it was too salty! Team B, however, had a different idea. They cooked small portions, tasted with the judges, and asked for feedback. They added a little more pepper, then a little more seasoning. By the end, they had created the perfect Jollof rice – and they won the competition! Team B used Agile. They worked in small steps, got feedback early, and kept improving. That's what Agile is all about!

Main Lessons

Lesson 1: What is Agile?

Definition: Agile is a way of working where teams build products in small pieces, get feedback often, and keep improving.

Why it is important: It helps teams build the right thing, faster, and with less wasted effort.

Simple explanation: It's like drawing a picture – you draw a little, ask if it looks good, then add more. You don't draw the whole picture without showing anyone.

Real-life example: A software team builds a small feature, shows it to users, then builds the next feature.

School example: A teacher gives a small assignment, checks it, then gives the next one.

Home example: You clean one room, then ask your parents if it's good, then clean the next room.

Nigerian example: A Nigerian startup builds a basic app, shares it with beta testers, then adds more features based on feedback.

Illustration:

  Agile = Small steps + Feedback + Improvement
      

Mini summary: Agile is a way of working in small steps with lots of feedback.


Lesson 2: Why Agile was Born – The Old Way

Definition: The old way is called "Waterfall." You plan everything first, then build everything, then test everything at the end. It's like building a car without checking the engine until it's finished.

Why it is important: Waterfall was slow and risky. If you made a mistake, it was very expensive to fix.

Simple explanation: It's like baking a cake without tasting the batter – you might bake it and find out it's terrible.

Real-life example: A company spent 2 years building software, but when it launched, no one wanted it.

School example: A student writes a whole essay without showing the teacher, then gets a bad grade.

Home example: You paint the whole house one colour, then realise you don't like it.

Nigerian example: A Nigerian bank built a new system over 3 years, but it didn't work well with existing systems.

Illustration:

  Waterfall: Plan β†’ Build β†’ Test β†’ Finish (risky)
  Agile: Plan β†’ Build a little β†’ Test β†’ Improve β†’ Repeat
      

Mini summary: The old way (Waterfall) was slow and risky – Agile fixes that.


Lesson 3: The Agile Manifesto – The 4 Values

Definition: The Agile Manifesto is a document written by 17 software developers in 2001. It has 4 values that guide Agile teams.

Why it is important: These values are the heart of Agile – they tell us how to think and work.

Simple explanation: It's like a team's rulebook – but instead of rules, it's values that guide behaviour.

Real-life example: A team values talking to customers more than following a strict plan.

School example: A teacher values helping students understand more than just finishing the textbook.

Home example: A family values spending time together more than watching TV.

Nigerian example: A Nigerian tech team values delivering working software over writing lots of documents.

Illustration:

  Agile Values:
  1. Individuals and interactions over processes and tools
  2. Working software over comprehensive documentation
  3. Customer collaboration over contract negotiation
  4. Responding to change over following a plan
      

Mini summary: The Agile Manifesto has 4 values that guide how Agile teams work.


Lesson 4: Value 1 – People Over Processes

Definition: This means that people and how they talk to each other are more important than following strict rules or using fancy tools.

Why it is important: Good communication builds great teams. Tools and processes can't replace that.

Simple explanation: It's better to have a team that talks well and helps each other than to have a perfect schedule but unhappy people.

Real-life example: A team has a quick daily chat instead of writing long reports.

School example: A teacher asks students how they feel about the lesson, instead of just following the plan.

Home example: Family members discuss plans instead of just following a schedule.

Nigerian example: A Nigerian startup has a WhatsApp group where everyone shares ideas freely.

Illustration:

  People > Processes
  A good conversation is better than a perfect document.
      

Mini summary: People and their interactions matter more than processes and tools.


Lesson 5: Value 2 – Working Software Over Documentation

Definition: This means it's more important to have a working product than to have lots of written plans and reports.

Why it is important: A working product is what delivers value to users – not long documents.

Simple explanation: Would you rather have a working app or a 100-page plan for an app? Of course, the working app!

Real-life example: A team releases a simple version of their app to get feedback, instead of waiting to write perfect documentation.

School example: A student builds a small working model instead of writing a long report about it.

Home example: You bake one cookie to test the recipe, instead of writing a recipe book.

Nigerian example: A Nigerian fintech company launches a basic service, then adds features as they learn.

Illustration:

  Working Software > Documentation
  A real product is better than a perfect plan.
      

Mini summary: Working software is more valuable than lots of written documents.


Lesson 6: Value 3 – Customer Collaboration Over Contract Negotiation

Definition: This means you work closely with your customers (or users) instead of just agreeing on a contract and walking away.

Why it is important: Customers know what they need – you must talk to them often.

Simple explanation: It's like cooking for someone – you ask them what they like instead of just guessing.

Real-life example: A team has regular meetings with customers to show progress and get feedback.

School example: A student asks the teacher for feedback on a draft, instead of just submitting the final version.

Home example: You ask your family what they want for dinner before cooking.

Nigerian example: A Nigerian brand uses WhatsApp to get quick feedback from customers.

Illustration:

  Customer Collaboration > Contract Negotiation
  Work with customers, not just sign papers.
      

Mini summary: Collaborate with customers – don't just sign a contract and disappear.


Lesson 7: Value 4 – Responding to Change Over Following a Plan

Definition: This means it's better to be flexible and adapt to new information than to stick to a plan that is no longer working.

Why it is important: Things change – customers change their minds, technology changes, the market changes. Agile teams change with them.

Simple explanation: It's like going on a road trip – if there is a roadblock, you don't wait – you find a new route.

Real-life example: A team changes a feature because users gave new feedback.

School example: A student changes their project topic after finding better information.

Home example: You change your dinner plan if someone is not hungry.

Nigerian example: A Nigerian startup changes its business model based on customer feedback.

Illustration:

  Responding to Change > Following a Plan
  Be flexible – plans change, and that's okay.
      

Mini summary: Be ready to change your plan when things don't go as expected.


Lesson 8: The 12 Principles of Agile – A Deeper Look

Definition: The 12 principles are guidelines that explain how to put the 4 values into practice. They are like the "rules" of Agile.

Why it is important: They tell teams exactly what to do to be Agile.

Simple explanation: If the 4 values are the heart, the 12 principles are the hands – they do the work.

Real-life example: Principle: "Deliver working software frequently" – so a team releases small updates every week.

School example: Principle: "Welcome changing requirements" – a student changes their essay topic if they find better ideas.

Home example: Principle: "Business people and developers work together" – family members plan together.

Nigerian example: A Nigerian team follows the principle of "Reflect on how to become more effective" by having weekly check-ins.

Illustration:

  12 Principles = How to be Agile in practice.
      

Mini summary: The 12 principles are practical steps that guide Agile teams.


Lesson 9: Principle 1 – Satisfy Customers Through Early and Continuous Delivery

Definition: Deliver value to customers early and keep delivering it regularly – not just at the end.

Why it is important: Customers see progress and can give feedback early.

Simple explanation: It's like sending a friend a photo of your art as you paint, instead of waiting until it's finished.

Real-life example: A team releases a new feature every 2 weeks.

School example: A student shares a draft with the teacher for early feedback.

Home example: You show your parents your room as you clean it.

Nigerian example: A Nigerian delivery app launches in one city first, then expands.

Illustration:

  Early delivery β†’ Feedback β†’ Improve β†’ Deliver more
      

Mini summary: Deliver value to customers early and often.


Lesson 10: Principle 2 – Welcome Changing Requirements

Definition: Be open to changes, even late in the project. Agile teams know that change is natural and can improve the product.

Why it is important: Customers often don't know what they want until they see it – changes are a sign of learning.

Simple explanation: It's like drawing – you might start with a circle and decide it should be a square. That's okay!

Real-life example: A customer sees a demo and asks for a new feature – the team adds it.

School example: A teacher asks students to add a new section to their essay – they do it.

Home example: You are making a cake and decide to add chocolate chips – you go ahead and do it.

Nigerian example: A Nigerian restaurant adds a new meal to its menu based on customer requests.

Illustration:

  Change is welcome – it means we are learning.
      

Mini summary: Welcome changes – they make the product better.


Lesson 11: Principle 3 – Deliver Working Software Frequently

Definition: Release new versions of your product often – from every few weeks to every day.

Why it is important: Frequent delivery gives you quick feedback and reduces risk.

Simple explanation: It's like giving someone a small gift every week instead of one big gift at the end.

Real-life example: A game developer releases a new level every week.

School example: A student submits a small part of a project each week.

Home example: You clean one room every day instead of the whole house at once.

Nigerian example: A Nigerian news app updates its headlines multiple times a day.

Illustration:

  Frequent delivery = less risk, more feedback.
      

Mini summary: Deliver working software often – it reduces risk and keeps customers happy.


Lesson 12: Principle 4 – Business and Developers Work Together Daily

Definition: The people who know the business and the people who build the product should talk to each other every day.

Why it is important: It builds understanding and prevents misunderstandings.

Simple explanation: It's like a chef and a waiter talking about the menu every day – they work together.

Real-life example: A product owner joins the development team's daily stand-up.

School example: A teacher and student talk daily about the project.

Home example: Family members discuss weekly plans together.

Nigerian example: A Nigerian fintech company has daily cross-functional meetings.

Illustration:

  Business + Developers = Better products
      

Mini summary: Business people and developers should talk daily.


Lesson 13: Principle 5 – Build Projects Around Motivated Individuals

Definition: Give the team the environment and support they need, and trust them to do the work.

Why it is important: Motivated people do better work – they are happier and more creative.

Simple explanation: It's like giving someone a garden and the tools – they will grow beautiful flowers if they are supported.

Real-life example: A company lets developers choose what they want to work on.

School example: A teacher lets students choose their project topic.

Home example: A parent lets a child choose their own hobby.

Nigerian example: A Nigerian startup gives developers ownership of their projects.

Illustration:

  Motivated teams β†’ Great products
      

Mini summary: Support and trust your team – they will do great work.


Lesson 14: Principle 6 – The Most Efficient Way to Communicate is Face-to-Face

Definition: Talking to someone in person (or video call) is better than writing long messages or emails.

Why it is important: It's faster and reduces misunderstandings.

Simple explanation: It's like telling a story vs. writing a letter – the story is quicker and clearer.

Real-life example: A team has a quick daily stand-up meeting instead of sending daily emails.

School example: A teacher talks to a student instead of just writing comments.

Home example: You talk to your parents instead of leaving a note.

Nigerian example: A Nigerian team uses WhatsApp voice notes for quick communication.

Illustration:

  Face-to-face > Written messages
      

Mini summary: Face-to-face communication is the most effective.


Lesson 15: Principle 12 – Reflect and Adjust Regularly

Definition: Teams should regularly look at how they are working and make changes to improve.

Why it is important: Continuous improvement is the heart of Agile – you always get better.

Simple explanation: It's like reviewing your game play – you see what worked and what didn't, and you adjust.

Real-life example: A team has a retrospective at the end of every sprint to discuss improvements.

School example: A student reviews their study habits and changes them to improve.

Home example: A family talks about their weekly routine and makes changes.

Nigerian example: A Nigerian team has a monthly "lessons learned" meeting.

Illustration:

  Reflect β†’ Adjust β†’ Improve β†’ Repeat
      

Mini summary: Always reflect on how you work and make improvements.


Key Vocabulary (simple definitions)

  • Agile: A way of working in small steps with feedback.
  • Waterfall: The old way – plan everything first, then build everything.
  • Manifesto: A public declaration of beliefs and values.
  • Values: Important beliefs that guide behaviour.
  • Principles: Practical rules that guide actions.
  • Feedback: Information about how something is done, used to improve.
  • Iteration: A small cycle of work that you repeat.
  • Collaboration: Working together with others.

Important Concepts

  • Small steps: Agile breaks work into small, manageable pieces.
  • Feedback loop: You do a little, get feedback, and improve.
  • Flexibility: Agile teams are ready to change when needed.
  • Continuous improvement: Teams always try to get better.

Step-by-Step Explanations

How to Start an Agile Project

  1. Define a small piece of work (a "user story").
  2. Plan a short time-box (a "sprint") to complete it – usually 1-4 weeks.
  3. Build that small piece – code, test, and make it work.
  4. Show it to the customer and get feedback.
  5. Plan the next piece based on feedback.
  6. Repeat – each time you improve the product.

Teacher Notes

  • Use the Jollof rice story to make Agile relatable.
  • Encourage students to think of other examples of Agile in daily life.
  • Emphasise that Agile is not just for software – it can be used anywhere.
  • Use Nigerian examples to make it locally relevant.

Parent Tips

  • Discuss with your child how they can use Agile for school projects.
  • Encourage them to get feedback early and often.
  • Show them how you use small steps in your own work.

Interesting Facts & Did You Know?

  • Did you know? The Agile Manifesto was created by 17 people in a ski resort in Utah in 2001.
  • Interesting: Agile is used not just in software – but also in schools, hospitals, and even the military!
  • Did you know? The word "Agile" means "quick and nimble" – like a fast-moving athlete.
  • Nigeria: Many Nigerian startups and tech hubs use Agile to build products faster.

Remember This

  • Agile is about small steps and feedback.
  • There are 4 values and 12 principles that guide Agile.
  • People and interactions matter more than processes.
  • Working software is more important than documentation.
  • Collaborate with customers and be ready to change.

Common Mistakes

  • Thinking Agile is a process: Agile is a mindset, not a set of steps.
  • Not getting feedback early: Waiting too long to show work.
  • Resisting change: Not being flexible when things change.
  • Not communicating: Not talking to customers or teammates.

Best Practices

  • Work in small iterations.
  • Get feedback often.
  • Communicate openly with your team and customers.
  • Be ready to adapt.
  • Always reflect and improve.

Illustrations & Diagrams

Agile vs Waterfall

  Waterfall:
  Plan β†’ Design β†’ Build β†’ Test β†’ Deliver (one big step)

  Agile:
  Plan β†’ Build β†’ Test β†’ Feedback β†’ Plan β†’ Build β†’ Test β†’ Feedback ...
      

Agile Values – Quick View

  β”Œβ”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”
  β”‚  Individuals & interactions   >   Processes & tools          β”‚
  β”‚  Working software             >   Comprehensive documentationβ”‚
  β”‚  Customer collaboration       >   Contract negotiation       β”‚
  β”‚  Responding to change         >   Following a plan           β”‚
  β””β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”˜
      

Comparison Tables

Waterfall vs Agile

WaterfallAgile
Plan everything firstPlan in small steps
Feedback at the endFeedback throughout
Hard to changeEasy to change
RiskyLess risky
Long delivery timeShort delivery cycles

Agile Values vs Traditional Values

Agile ValueTraditional Value
People over processesProcesses over people
Working software over docsDocs over working software
Customer collaborationContract negotiation
Responding to changeSticking to the plan

End-of-Module Summary

Great job! You have learned the foundation of Agile. You now know what Agile is, where it came from, and why it is better than the old Waterfall way. You understand the 4 values of the Agile Manifesto and the 12 principles that guide Agile teams. Remember, Agile is a mindset – it's about working in small steps, getting feedback, and being ready to change. In the next module, we will dive into Scrum – the most popular Agile framework. Get ready!

Frequently Asked Questions (10)

  1. What is Agile? A way of working in small steps with lots of feedback.
  2. What is Waterfall? The old way – plan everything first, then build everything.
  3. What is the Agile Manifesto? A document with 4 values that guide Agile.
  4. How many Agile values are there? 4.
  5. How many Agile principles are there? 12.
  6. What does "people over processes" mean? People and communication matter more than rules.
  7. What does "working software" mean? A product that actually works is more valuable than documentation.
  8. What is customer collaboration? Working with customers, not just signing contracts.
  9. Why should I respond to change? Because plans change – being flexible is better.
  10. Is Agile only for software? No – it can be used in many areas.

Review Questions (15)

  1. What is Agile?
  2. What is Waterfall?
  3. What is the Agile Manifesto?
  4. How many values does the Agile Manifesto have?
  5. Name one Agile value.
  6. How many principles does Agile have?
  7. What does "people over processes" mean?
  8. What does "working software" mean?
  9. What does "customer collaboration" mean?
  10. What does "responding to change" mean?
  11. Why is feedback important in Agile?
  12. What is an iteration?
  13. What is collaboration?
  14. Can Agile be used outside of software?
  15. What is the most important thing to remember about Agile?

Fill-in-the-Blank Exercises

  1. Agile is a way of working in small _______ with feedback. (steps)
  2. _______ is the old way – plan everything first. (Waterfall)
  3. The Agile Manifesto has _______ values. (4)
  4. The Agile Manifesto has _______ principles. (12)
  5. _______ over processes is an Agile value. (People)
  6. _______ software is more important than documentation. (Working)

True or False Exercises

  1. Agile is only for software development. (False)
  2. Waterfall is the new way of building software. (False)
  3. The Agile Manifesto has 4 values. (True)
  4. Agile principles help guide how to work. (True)
  5. In Agile, you should never change your plan. (False)

Multiple Choice Questions (15)

  1. What is Agile?
    A) A game
    B) A way of working with small steps and feedback
    C) A type of food
    Answer: B
  2. What is Waterfall?
    A) The old way of building software
    B) A type of water
    C) An Agile value
    Answer: A
  3. How many values does the Agile Manifesto have?
    A) 1
    B) 4
    C) 12
    Answer: B
  4. How many principles does Agile have?
    A) 4
    B) 12
    C) 20
    Answer: B
  5. Which is an Agile value?
    A) People over processes
    B) Processes over people
    C) Documentation over working software
    Answer: A
  6. What does "working software" mean?
    A) A product that works
    B) A document about a product
    C) A plan for a product
    Answer: A
  7. What does "customer collaboration" mean?
    A) Working with customers
    B) Signing a contract
    C) Ignoring customers
    Answer: A
  8. What does "responding to change" mean?
    A) Being flexible
    B) Sticking to the plan
    C) Ignoring change
    Answer: A
  9. What is an iteration?
    A) A small cycle of work
    B) A large project
    C) A document
    Answer: A
  10. Is Agile only for software?
    A) Yes
    B) No
    C) Only in Nigeria
    Answer: B
  11. What is the Agile Manifesto?
    A) A document with values and principles
    B) A type of software
    C) A game
    Answer: A
  12. What does "individuals and interactions" mean?
    A) People and communication are important
    B) Tools are more important
    C) Processes are more important
    Answer: A
  13. Why is feedback important?
    A) To improve
    B) To finish faster
    C) To avoid work
    Answer: A
  14. What is a principle?
    A) A rule that guides action
    B) A type of food
    C) A game
    Answer: A
  15. What is collaboration?
    A) Working together
    B) Working alone
    C) Not working
    Answer: A

Matching Exercises

TermMeaning
1. AgileA. Old way of building software
2. WaterfallB. Small steps with feedback
3. ManifestoC. Document with values
4. ValueD. Important belief
5. PrincipleE. Practical rule

Answers: 1-B, 2-A, 3-C, 4-D, 5-E

Short Answer Questions

  1. What is Agile?
  2. What is the difference between Waterfall and Agile?
  3. Name two Agile values.
  4. What is the Agile Manifesto?

Scenario-based Exercises

  • Scenario 1: You are building a new app. The customer changes their mind about a feature. How would you handle it using Agile?
  • Scenario 2: Your team has been working for 6 months on a project without showing the customer. What would an Agile team do differently?
  • Scenario 3: A teammate suggests following a strict plan and not changing it. How would you explain Agile to them?

Group Activity

In groups, think of a project (like planning a birthday party). Plan it using Waterfall (all details first) and then using Agile (small steps, feedback). Compare the two approaches.

Individual Activity

Write your own "Agile Manifesto" for your schoolwork – 4 values that will guide how you study and do projects.

Classroom Discussion Questions

  • Can you think of a time when you used Agile without knowing it?
  • Why do you think many people still use Waterfall?
  • How could Agile help you in your daily life?

Mini Project

Create a poster that explains Agile in simple words. Include the 4 values and 12 principles (or the most important ones).

Practical Assignment

Find an example of Agile in action – it could be a company, a team, or even a friend. Write a short report on how they use Agile.

Challenge Exercise

Research how a Nigerian company uses Agile. Write a short summary of what you learn.

Quiz Answers

Multiple Choice answers: 1-B, 2-A, 3-B, 4-B, 5-A, 6-A, 7-A, 8-A, 9-A, 10-B, 11-A, 12-A, 13-A, 14-A, 15-A.

True/False answers: 1-F, 2-F, 3-T, 4-T, 5-F.

Key Takeaways

  • Agile is a way of working in small steps with feedback.
  • The Agile Manifesto has 4 values and 12 principles.
  • People, working software, customer collaboration, and adapting to change are key.
  • Agile is better than Waterfall because it reduces risk and delivers value faster.
  • Agile is a mindset, not just a process – it can be used in many areas.

Preparation for the Next Module

In Module 2, we will explore Scrum – the most popular Agile framework. You will learn about the Scrum roles (Scrum Master, Product Owner, and Development Team), the events (Sprint, Planning, Daily Stand-up), and the artifacts (Product Backlog, Sprint Backlog). Get ready to start Scrumming!

3

Module Two

Module 2: Scrum – The Most Popular Agile Framework

Module Two: Scrum – The Most Popular Agile Framework

Module Introduction

Hello, future Scrum master! πŸ‰ In Module 1, we learned what Agile is and why it works. Now we are going to explore Scrum – the most popular way to do Agile. Scrum is like a playbook for teams. It tells you who does what, when things happen, and how to keep improving. If Agile is the philosophy, Scrum is the practical way to put it into action. By the end of this module, you'll understand the key parts of Scrum: the roles, the events, and the artifacts. Let's jump in!

Learning Objectives

By the end of this module, you will be able to:

  • Explain what Scrum is and how it works.
  • Identify the three Scrum roles: Product Owner, Scrum Master, and Development Team.
  • Describe the five Scrum events: Sprint, Sprint Planning, Daily Scrum, Sprint Review, and Sprint Retrospective.
  • Understand the three Scrum artifacts: Product Backlog, Sprint Backlog, and Increment.
  • Recognise the importance of the "Definition of Done".

Warm-up Story: The Football Team That Used Scrum

There was a football team in Lagos called the "Agile Eagles." They used to have a coach who made all the decisions. But they kept losing. One day, a new coach arrived and said, "We will use Scrum!" He gave the players roles: a captain (like a Product Owner) who decided what the team needed to improve, a coach (like a Scrum Master) who helped the team work better, and the players (the Development Team) who did the work. They had short "sprints" – each week they focused on one thing, like passing or shooting. After each week, they reviewed what they did and planned the next week. They got better and started winning. That's Scrum!

Main Lessons

Lesson 1: What is Scrum?

Definition: Scrum is a framework for developing and sustaining complex products. It's a way of working that helps teams deliver value in short cycles.

Why it is important: Scrum gives teams a clear structure – who does what, when, and how to keep improving.

Simple explanation: It's like a recipe for baking a cake – it tells you the ingredients (roles), steps (events), and the final product (artifact).

Real-life example: A software team uses Scrum to build an app – they work in 2-week sprints.

School example: A group project uses Scrum – each week they review what they did and plan the next week.

Home example: A family uses Scrum to plan a vacation – they meet weekly to review progress.

Nigerian example: A Nigerian fintech startup uses Scrum to build their mobile app in small pieces.

Illustration:

  Scrum = Roles + Events + Artifacts
      

Mini summary: Scrum is a framework that gives Agile teams a clear structure.


Lesson 2: The Three Scrum Roles

Definition: Scrum has three roles: the Product Owner, the Scrum Master, and the Development Team. Each has a specific job.

Why it is important: Clear roles mean less confusion and better teamwork.

Simple explanation: It's like a football team – you have a captain, a coach, and the players.

Real-life example: In a company, the Product Owner decides what features to build, the Scrum Master helps the team work better, and the Developers build the features.

School example: In a group project, one person is the leader (Product Owner), one helps the team (Scrum Master), and the others do the work (Development Team).

Home example: Planning a party – one person decides the theme, one helps organise, and everyone else helps with the tasks.

Nigerian example: A Nigerian tech startup has a Product Owner (the founder), a Scrum Master (a senior developer), and the development team.

Illustration:

  Scrum Roles:
  Product Owner   β†’  Decides what to build
  Scrum Master    β†’  Helps team work better
  Development Team β†’  Builds the product
      

Mini summary: Scrum has three roles – each with a clear responsibility.


Lesson 3: The Product Owner – The Voice of the Customer

Definition: The Product Owner is responsible for maximising the value of the product. They manage the Product Backlog and represent the customer's interests.

Why it is important: The Product Owner ensures the team builds the right things.

Simple explanation: The Product Owner is like the captain of a ship – they decide which direction to go.

Real-life example: A Product Owner decides which features to build first based on customer needs.

School example: A student leader decides which topics the group will study first.

Home example: A parent decides which chores to do first.

Nigerian example: A Nigerian Product Owner talks to customers to understand what they need most.

Illustration:

  Product Owner = Decides what to build
  They manage the Product Backlog (the to-do list).
      

Mini summary: The Product Owner decides what features to build and prioritises the work.


Lesson 4: The Scrum Master – The Team's Coach

Definition: The Scrum Master is a servant-leader who helps the team follow Scrum, removes obstacles, and facilitates events.

Why it is important: The Scrum Master ensures the team can work efficiently and improve.

Simple explanation: The Scrum Master is like a coach – they help the team play better together.

Real-life example: A Scrum Master helps the team resolve conflicts and removes distractions.

School example: A teacher's assistant helps the group stay on track.

Home example: A parent helps family members work together on a project.

Nigerian example: A Nigerian Scrum Master helps a remote team collaborate effectively.

Illustration:

  Scrum Master = Helps team work better
  They remove obstacles and guide the team.
      

Mini summary: The Scrum Master supports the team and helps them follow Scrum.


Lesson 5: The Development Team – The Builders

Definition: The Development Team is a group of professionals who do the work – they design, build, test, and deliver the product.

Why it is important: They are the ones who turn ideas into working products.

Simple explanation: The Development Team is like the builders – they construct the product.

Real-life example: Developers, designers, and testers who build the software.

School example: Students who do the research, write, and present a project.

Home example: Family members who set up the decorations, cook, and clean for a party.

Nigerian example: A Nigerian team of developers builds a mobile app for a client.

Illustration:

  Development Team = Builds the product
  They are self-organising – they decide how to do the work.
      

Mini summary: The Development Team is responsible for building the product.


Lesson 6: The Sprint – A Time-Boxed Iteration

Definition: A Sprint is a short, fixed time period (usually 1-4 weeks) during which the team works to complete a set of work.

Why it is important: Sprints create a rhythm and help the team focus.

Simple explanation: It's like a race – you run for a set time, then stop and see how you did.

Real-life example: A team does a 2-week Sprint – they plan, build, and review in those 2 weeks.

School example: A class has a 1-week "Sprint" to finish a chapter.

Home example: A family does a 1-day "Sprint" to clean the house.

Nigerian example: A Nigerian startup uses 2-week Sprints to build and test new features.

Illustration:

  Sprint = A short, focused work period
  Usually 1-4 weeks long.
      

Mini summary: A Sprint is a fixed time period where the team works on a set of tasks.


Lesson 7: Sprint Planning – Setting the Goal

Definition: Sprint Planning is an event at the beginning of the Sprint where the team decides what work to do and how to do it.

Why it is important: It sets the direction for the Sprint.

Simple explanation: It's like a game plan before a match – you decide what you will achieve.

Real-life example: The team decides to build the login feature in the next Sprint.

School example: A group decides which parts of the project to finish by Friday.

Home example: A family decides which rooms to clean and who does what.

Nigerian example: A Nigerian team plans the Sprint – they pick user stories from the backlog.

Illustration:

  Sprint Planning:
  1. Decide what to build (Sprint Goal)
  2. Plan how to build it (tasks)
      

Mini summary: Sprint Planning is where the team plans the work for the Sprint.


Lesson 8: Daily Scrum – The Stand-up Meeting

Definition: The Daily Scrum (or stand-up) is a short 15-minute meeting held every day. The team answers three questions: What did I do yesterday? What will I do today? Any obstacles?

Why it is important: It keeps everyone aligned and helps identify problems early.

Simple explanation: It's like a quick morning check-in – you see how everyone is doing and if anyone needs help.

Real-life example: The team stands in a circle and each person quickly shares their progress.

School example: A group has a quick 5-minute meeting each morning to plan the day.

Home example: A family has a quick chat at breakfast to plan the day.

Nigerian example: A Nigerian team has a daily stand-up via video call.

Illustration:

  Daily Scrum (Stand-up):
  - What did I do yesterday?
  - What will I do today?
  - Any blockers?
      

Mini summary: The Daily Scrum is a short daily meeting to keep the team synchronised.


Lesson 9: Sprint Review – Show and Tell

Definition: The Sprint Review is an event at the end of the Sprint where the team shows what they built and gets feedback.

Why it is important: It ensures the team is building the right thing and gets early feedback.

Simple explanation: It's like a show-and-tell – you show your work and get comments.

Real-life example: The team demonstrates the new login feature to the Product Owner and stakeholders.

School example: A student presents a draft of their project to the teacher.

Home example: A child shows their cleaned room to their parents.

Nigerian example: A Nigerian team presents a new feature to the client for feedback.

Illustration:

  Sprint Review:
  1. Show what was built.
  2. Get feedback.
  3. Update the backlog.
      

Mini summary: The Sprint Review is where the team shows what they've done and gets feedback.


Lesson 10: Sprint Retrospective – Learning and Improving

Definition: The Sprint Retrospective is a meeting at the end of the Sprint where the team reflects on how they worked and identifies improvements.

Why it is important: It's the engine of continuous improvement – the team gets better with each Sprint.

Simple explanation: It's like a post-game review – you discuss what went well and what to improve.

Real-life example: The team discusses that they need better communication and decides to try a new tool.

School example: A study group discusses what study methods worked and what didn't.

Home example: A family discusses how the week went and plans to improve.

Nigerian example: A Nigerian team decides to have shorter meetings after a retrospective.

Illustration:

  Sprint Retrospective:
  1. What went well?
  2. What went wrong?
  3. What can we improve?
      

Mini summary: The Sprint Retrospective helps the team improve how they work.


Lesson 11: The Product Backlog – The To-Do List

Definition: The Product Backlog is a list of all the work that needs to be done on the product. It is ordered by priority.

Why it is important: It helps the team know what to work on next.

Simple explanation: It's like a shopping list – you have a list of things to buy, and you prioritise what you need most.

Real-life example: A Product Backlog includes user stories like "As a user, I want to log in" and "As a user, I want to reset my password."

School example: A study plan with topics to cover, prioritised by importance.

Home example: A list of chores, ordered by urgency.

Nigerian example: A Nigerian brand has a backlog of features for their e-commerce platform.

Illustration:

  Product Backlog = Ordered list of work
  - Top items: most important
  - Bottom items: less important
      

Mini summary: The Product Backlog is a prioritised list of work to be done.


Lesson 12: The Sprint Backlog – What We're Doing Now

Definition: The Sprint Backlog is the list of work the team commits to completing in the current Sprint.

Why it is important: It gives the team a clear focus for the Sprint.

Simple explanation: It's like a daily to-do list – what you plan to accomplish today.

Real-life example: The team picks 5 user stories from the Product Backlog for the Sprint.

School example: A student lists the assignments they will complete this week.

Home example: A family lists the chores they will do on Saturday.

Nigerian example: A Nigerian team selects a set of features to build in the next 2 weeks.

Illustration:

  Sprint Backlog = Work for the current Sprint
  - Selected from the Product Backlog
  - The team commits to completing it.
      

Mini summary: The Sprint Backlog is the team's focus for the current Sprint.


Lesson 13: The Increment – What We've Built

Definition: The Increment is the sum of all the work completed in the Sprint, plus all previous Sprints. It's a working product that adds value.

Why it is important: It shows what the team has delivered – it must be "done" and usable.

Simple explanation: It's like building with Lego – each Sprint you add more pieces to the structure.

Real-life example: At the end of the Sprint, the team has a new working feature that can be shown to users.

School example: After each week, the student has a completed part of the project.

Home example: After each day, the room is cleaner than before.

Nigerian example: A Nigerian startup releases a new version of their app every Sprint.

Illustration:

  Increment = Sum of all completed work
  - Must be "done" and usable
  - Adds value to the product.
      

Mini summary: The Increment is the working product built during the Sprint.


Lesson 14: Definition of Done – When is Work Complete?

Definition: The Definition of Done is a checklist of criteria that must be met for a work item to be considered "done".

Why it is important: It ensures everyone agrees on what "done" means – no surprises.

Simple explanation: It's like a checklist for finishing a task – you must check all the boxes before you say it's done.

Real-life example: A team's Definition of Done includes: code written, tested, reviewed, and documented.

School example: A project is done when: research is complete, written, proofread, and presented.

Home example: A room is done when: it's vacuumed, dusted, and the bed is made.

Nigerian example: A Nigerian team's Definition of Done includes: code reviewed, unit tests passed, and acceptance criteria met.

Illustration:

  Definition of Done = Checklist for "done"
  - Code written
  - Tested
  - Reviewed
  - Documented
      

Mini summary: The Definition of Done ensures everyone knows what it means to finish a task.


Lesson 15: Putting It All Together – A Scrum Cycle

Definition: A Scrum cycle is the complete flow from Sprint Planning to Sprint Retrospective.

Why it is important: It shows how all the pieces fit together.

Simple explanation: It's like a dance – each step leads to the next, and you repeat the dance each Sprint.

Real-life example: A team goes through Sprint Planning, Daily Scrums, Sprint Review, and Retrospective in each Sprint.

School example: A student plans, works, reviews, and improves each week.

Home example: A family plans the week, works on tasks, checks progress, and reflects.

Nigerian example: A Nigerian team runs a complete Scrum cycle every 2 weeks.

Illustration:

  Scrum Cycle:
  Sprint Planning β†’ Work (Daily Scrums) β†’ Sprint Review β†’ Sprint Retrospective β†’ Repeat
      

Mini summary: The Scrum cycle is a repeatable flow that helps teams deliver value continuously.


Key Vocabulary (simple definitions)

  • Scrum: A framework for Agile development with roles, events, and artifacts.
  • Product Owner: Person who decides what to build and prioritises the backlog.
  • Scrum Master: Coach who helps the team follow Scrum and removes obstacles.
  • Development Team: People who build the product.
  • Sprint: A fixed time period (1-4 weeks) for work.
  • Product Backlog: A prioritised list of all work.
  • Sprint Backlog: Work planned for the current Sprint.
  • Increment: The working product built during the Sprint.
  • Definition of Done: A checklist for when work is complete.

Important Concepts

  • Roles: Clear responsibilities ensure accountability.
  • Events: Regular events keep the team aligned and focused.
  • Artifacts: Lists and increments help track progress.
  • Continuous improvement: The Retrospective is the heart of learning.

Step-by-Step Explanations

How a Sprint Works

  1. Sprint Planning: The team selects work from the Product Backlog and creates a Sprint Backlog.
  2. Sprint: The team works on the tasks – they hold Daily Scrums to synchronise.
  3. Sprint Review: The team shows the completed work to stakeholders and gets feedback.
  4. Sprint Retrospective: The team reflects on their process and identifies improvements.
  5. Repeat: The next Sprint starts with a new Sprint Planning.

Teacher Notes

  • Use the football team analogy to explain roles.
  • Encourage students to act out a Scrum cycle in class.
  • Emphasise that the Sprint Retrospective is the most important event for improvement.
  • Use Nigerian examples to make it locally relevant.

Parent Tips

  • Help your child apply Scrum to their school projects.
  • Teach them to set a "Definition of Done" for their tasks.
  • Encourage them to reflect on what they did well and what to improve.

Interesting Facts & Did You Know?

  • Did you know? The word "Scrum" comes from rugby – it's where the team huddles to restart the game.
  • Interesting: Scrum was created by Ken Schwaber and Jeff Sutherland in the 1990s.
  • Did you know? Many of the world's largest companies use Scrum, including Google, Amazon, and Microsoft.
  • Nigeria: Nigerian startups like Flutterwave and Paystack use Scrum to build their products.

Remember This

  • Scrum has 3 roles: Product Owner, Scrum Master, Development Team.
  • Scrum has 5 events: Sprint, Sprint Planning, Daily Scrum, Sprint Review, Sprint Retrospective.
  • Scrum has 3 artifacts: Product Backlog, Sprint Backlog, Increment.
  • The Definition of Done ensures everyone agrees on what "done" means.

Common Mistakes

  • No Product Owner: Without a Product Owner, the team builds the wrong things.
  • Scrum Master as a manager: The Scrum Master is a coach, not a boss.
  • Long Sprints: Sprints should be short – 1-4 weeks.
  • Skipping the Retrospective: Without it, the team doesn't improve.

Best Practices

  • Keep Sprints short and consistent.
  • Hold a Daily Scrum every day.
  • Always hold a Sprint Retrospective.
  • Maintain a clear Definition of Done.
  • The Product Owner should be available to the team.

Illustrations & Diagrams

Scrum Framework Overview

  β”Œβ”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”
  β”‚  Scrum Framework                                            β”‚
  β”œβ”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€
  β”‚  Roles:        Product Owner, Scrum Master, Dev Team        β”‚
  β”‚  Events:       Sprint, Planning, Daily, Review, Retro       β”‚
  β”‚  Artifacts:    Product Backlog, Sprint Backlog, Increment   β”‚
  β””β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”˜
      

A Sprint Cycle

  Sprint Planning
       ↓
  Sprint (1-4 weeks)
       ↓
  Daily Scrum (each day)
       ↓
  Sprint Review
       ↓
  Sprint Retrospective
       ↓
  Repeat
      

Comparison Tables

Scrum Roles at a Glance

RoleResponsibility
Product OwnerDecides what to build, manages backlog
Scrum MasterCoaches the team, removes obstacles
Development TeamBuilds the product

Scrum Events Overview

EventPurposeDuration
Sprint PlanningPlan the SprintMax 8 hours (for 1-month Sprint)
Daily ScrumSync the team15 minutes
Sprint ReviewShow work, get feedbackMax 4 hours
Sprint RetrospectiveReflect and improveMax 3 hours

End-of-Module Summary

Well done! You now have a solid understanding of Scrum – the most popular Agile framework. You know the three roles (Product Owner, Scrum Master, Development Team), the five events (Sprint, Sprint Planning, Daily Scrum, Sprint Review, Sprint Retrospective), and the three artifacts (Product Backlog, Sprint Backlog, Increment). You also learned about the Definition of Done. Remember, Scrum is a simple but powerful framework that helps teams deliver value consistently. In the next module, we will dive deeper into user stories and backlog refinement – how to write great requirements for your team. Keep going!

Frequently Asked Questions (10)

  1. What is Scrum? A framework for Agile development.
  2. How many roles are there in Scrum? Three: Product Owner, Scrum Master, Development Team.
  3. What does the Product Owner do? Decides what to build and prioritises the backlog.
  4. What does the Scrum Master do? Helps the team follow Scrum and removes obstacles.
  5. What is a Sprint? A fixed time period for work – 1-4 weeks.
  6. What is the Daily Scrum? A 15-minute daily meeting to sync the team.
  7. What is a Sprint Review? A meeting to show work and get feedback.
  8. What is a Sprint Retrospective? A meeting to reflect and improve.
  9. What is the Product Backlog? A prioritised list of all work.
  10. What is the Definition of Done? A checklist for when work is complete.

Review Questions (15)

  1. What is Scrum?
  2. Name the three Scrum roles.
  3. What does the Product Owner do?
  4. What does the Scrum Master do?
  5. What does the Development Team do?
  6. What is a Sprint?
  7. What happens in Sprint Planning?
  8. What is the Daily Scrum?
  9. What is the Sprint Review?
  10. What is the Sprint Retrospective?
  11. What is the Product Backlog?
  12. What is the Sprint Backlog?
  13. What is the Increment?
  14. What is the Definition of Done?
  15. Why is the Retrospective important?

Fill-in-the-Blank Exercises

  1. Scrum has three roles: Product Owner, Scrum Master, and _______ Team. (Development)
  2. A _______ is a fixed time period for work. (Sprint)
  3. The _______ Backlog is a prioritised list of all work. (Product)
  4. The _______ Backlog is work for the current Sprint. (Sprint)
  5. The _______ is the working product built during the Sprint. (Increment)
  6. The _______ of Done is a checklist for when work is complete. (Definition)

True or False Exercises

  1. The Product Owner is the same as the Scrum Master. (False)
  2. A Sprint can be 6 months long. (False)
  3. The Daily Scrum is a 15-minute meeting. (True)
  4. The Sprint Review is where the team gets feedback. (True)
  5. The Sprint Retrospective is optional. (False)

Multiple Choice Questions (15)

  1. What is Scrum?
    A) A game
    B) An Agile framework
    C) A type of food
    Answer: B
  2. How many roles are in Scrum?
    A) 1
    B) 3
    C) 5
    Answer: B
  3. Who decides what to build?
    A) Scrum Master
    B) Product Owner
    C) Development Team
    Answer: B
  4. Who helps the team follow Scrum?
    A) Product Owner
    B) Scrum Master
    C) Development Team
    Answer: B
  5. Who builds the product?
    A) Product Owner
    B) Scrum Master
    C) Development Team
    Answer: C
  6. What is a Sprint?
    A) A running race
    B) A fixed work period
    C) A type of meeting
    Answer: B
  7. How long is a typical Sprint?
    A) 1 day
    B) 1-4 weeks
    C) 1 year
    Answer: B
  8. What is the Daily Scrum?
    A) A 15-minute meeting
    B) A 2-hour meeting
    C) A weekly meeting
    Answer: A
  9. What is the Sprint Review?
    A) Show work and get feedback
    B) Plan the Sprint
    C) Reflect on the Sprint
    Answer: A
  10. What is the Sprint Retrospective?
    A) Show work
    B) Plan work
    C) Reflect and improve
    Answer: C
  11. What is the Product Backlog?
    A) All work to be done
    B) Work for the current Sprint
    C) Completed work
    Answer: A
  12. What is the Sprint Backlog?
    A) All work
    B) Work for the current Sprint
    C) Completed work
    Answer: B
  13. What is the Increment?
    A) All work
    B) Work for the current Sprint
    C) Completed work
    Answer: C
  14. What is the Definition of Done?
    A) A checklist
    B) A meeting
    C) A role
    Answer: A
  15. Which event helps the team improve?
    A) Sprint Planning
    B) Sprint Review
    C) Sprint Retrospective
    Answer: C

Matching Exercises

TermMeaning
1. Product OwnerA. Decides what to build
2. Scrum MasterB. Helps team follow Scrum
3. SprintC. Fixed work period
4. Product BacklogD. All work to be done
5. IncrementE. Completed work

Answers: 1-A, 2-B, 3-C, 4-D, 5-E

Short Answer Questions

  1. What are the three Scrum roles?
  2. What is the purpose of the Sprint Retrospective?
  3. What is the difference between the Product Backlog and the Sprint Backlog?
  4. What is the Definition of Done?

Scenario-based Exercises

  • Scenario 1: Your team is building a new app. The Product Owner keeps changing the requirements. How does Scrum help?
  • Scenario 2: Your team's Sprint Review shows that the work is not what the customer wanted. What would you do?
  • Scenario 3: The team is not improving even after several Sprints. What could be missing?

Group Activity

In groups, simulate a Scrum cycle. Choose a simple project, assign roles (Product Owner, Scrum Master, Development Team), and run a Sprint Planning, Daily Scrum, Sprint Review, and Retrospective.

Individual Activity

Write a 2-page summary of how you would use Scrum to complete a school project. Include the roles, events, and artifacts you would use.

Classroom Discussion Questions

  • Which Scrum role would you like to have and why?
  • What would happen if you skipped the Sprint Retrospective?
  • How can Scrum help you in your personal life?

Mini Project

Create a visual poster that explains Scrum. Include the roles, events, and artifacts with simple illustrations.

Practical Assignment

Find a team or organisation that uses Scrum (or another Agile framework). Interview them and write a report on how they use it.

Challenge Exercise

Research how a Nigerian company uses Scrum. Write a summary of what you find and share with the class.

Quiz Answers

Multiple Choice answers: 1-B, 2-B, 3-B, 4-B, 5-C, 6-B, 7-B, 8-A, 9-A, 10-C, 11-A, 12-B, 13-C, 14-A, 15-C.

True/False answers: 1-F, 2-F, 3-T, 4-T, 5-F.

Key Takeaways

  • Scrum has 3 roles: Product Owner, Scrum Master, Development Team.
  • Scrum has 5 events: Sprint, Sprint Planning, Daily Scrum, Sprint Review, Sprint Retrospective.
  • Scrum has 3 artifacts: Product Backlog, Sprint Backlog, Increment.
  • The Definition of Done ensures clarity on what "done" means.
  • Scrum is a powerful framework for delivering value in short cycles.

Preparation for the Next Module

In Module 3, we will learn about User Stories and Backlog Refinement. You will learn how to write great user stories, use the INVEST criteria, and refine your backlog for success. Get ready to become a backlog expert!

4

Module Three

Module 3: User Stories and Backlog Refinement

Module Three: User Stories and Backlog Refinement – Writing Great Requirements

Module Introduction

Hello, story writer! πŸ“ In Modules 1 and 2, you learned about Agile and Scrum. Now we are going to learn how to write user stories – the building blocks of any Agile project. User stories are simple, short descriptions of what a user wants to do. They help the team understand what to build and why. We'll also learn about backlog refinement – the process of keeping your Product Backlog clean and ready. This is a very important skill for any Agile developer. Let's get started!

Learning Objectives

By the end of this module, you will be able to:

  • Explain what a user story is and why it's important.
  • Write a user story using the "As a... I want... So that..." format.
  • Apply the INVEST criteria to create good user stories.
  • Write clear acceptance criteria.
  • Understand and participate in backlog refinement.

Warm-up Story: The Market Woman's Request

In a busy market in Lagos, a woman named Mama Nkechi sold the best tomatoes. She wanted an app to track her sales. The developer, Tunde, asked her, "What do you want the app to do?" Mama Nkechi said, "I want to enter how many tomatoes I sell each day, and I want to see my total sales." Tunde wrote: "As a tomato seller, I want to enter my daily sales so that I can see my total revenue." That was a user story! It was short, clear, and focused on what Mama Nkechi needed. Tunde and his team built exactly that, and Mama Nkechi was very happy. That's the power of a good user story!

Main Lessons

Lesson 1: What is a User Story?

Definition: A user story is a short, simple description of a feature from the perspective of the user. It explains who wants the feature, what they want, and why.

Why it is important: User stories help the team understand what the user needs. They keep the focus on the user, not just on building features.

Simple explanation: It's like asking a friend, "What do you want this thing to do?" and they tell you in one sentence.

Real-life example: "As a shopper, I want to search for products by name so I can find what I'm looking for."

School example: "As a student, I want to check my grades online so I can know how I'm doing."

Home example: "As a parent, I want to set reminders for school events so I don't forget."

Nigerian example: "As a customer, I want to pay with USSD so I can buy airtime easily."

Illustration:

  User Story = As a [user], I want [action] so that [benefit].
      

Mini summary: A user story is a short description of what a user needs and why.


Lesson 2: The 3 Cs of User Stories

Definition: The 3 Cs are Card, Conversation, and Confirmation. They represent the key elements of a good user story.

Why it is important: They remind us that a story is not just a written note – it's a conversation and an agreement.

Simple explanation: It's like ordering food – you write it (Card), you discuss it with the waiter (Conversation), and you confirm you got what you asked for (Confirmation).

Real-life example: The story is written on a card, the team discusses it, and they confirm it meets the acceptance criteria.

School example: A student writes a task, discusses it with the group, and confirms it's done.

Home example: A parent writes a chore list, discusses it with the family, and confirms each chore is done.

Nigerian example: A Nigerian team writes a story, discusses it during backlog refinement, and confirms it's ready for the Sprint.

Illustration:

  3 Cs:
  Card         β†’   Write the story
  Conversation β†’   Discuss it with the team
  Confirmation β†’   Confirm it meets the acceptance criteria
      

Mini summary: The 3 Cs remind us that a user story is a conversation, not just a written note.


Lesson 3: The INVEST Criteria – Writing Good Stories

Definition: INVEST is an acronym that helps you write good user stories: Independent, Negotiable, Valuable, Estimable, Small, and Testable.

Why it is important: It gives you a checklist to make sure your stories are well-written and ready for development.

Simple explanation: It's like a recipe – you check each ingredient to make sure you have everything.

Real-life example: A story that is too big might not be "Small" – you might need to break it down.

School example: A project task that can be done in one day is "Small" – a task that takes a month is not.

Home example: Cleaning one room is "Small" – cleaning the whole house is not.

Nigerian example: A Nigerian team uses INVEST to review their stories during backlog refinement.

Illustration:

  INVEST:
  I – Independent
  N – Negotiable
  V – Valuable
  E – Estimable
  S – Small
  T – Testable
      

Mini summary: INVEST is a checklist for writing good user stories.


Lesson 4: I – Independent

Definition: A story should be independent – it should not depend on another story to be built.

Why it is important: If stories depend on each other, you can't build them in any order.

Simple explanation: It's like building with Lego – each block should be able to stand on its own.

Real-life example: The login feature can be built before the profile page – they are independent.

School example: Researching a topic can be done before writing the essay – independent tasks.

Home example: Cleaning the kitchen and cleaning the bedroom are independent.

Nigerian example: A Nigerian team makes sure their stories are independent so they can work in parallel.

Illustration:

  Independent = Can be built separately
      

Mini summary: Independent stories can be built in any order.


Lesson 5: N – Negotiable

Definition: A story should be negotiable – it can be discussed and changed if needed.

Why it is important: It allows the team to find the best solution, not just follow a rigid command.

Simple explanation: It's like planning a party – you can change the date if needed.

Real-life example: The team might decide to simplify a feature if it's too complex.

School example: A student can negotiate the deadline for an assignment with the teacher.

Home example: Family members can negotiate who does which chore.

Nigerian example: A Nigerian team negotiates the scope of a story with the Product Owner.

Illustration:

  Negotiable = Can be discussed and changed
      

Mini summary: Negotiable stories allow the team to find the best solution.


Lesson 6: V – Valuable

Definition: A story must deliver value to the user or the business. If it doesn't add value, why build it?

Why it is important: It ensures the team is always working on things that matter.

Simple explanation: It's like cooking – you only cook food that people will eat.

Real-life example: A story that adds a "share" button is valuable because users want to share.

School example: Studying for an exam is valuable – it helps you pass.

Home example: Buying groceries is valuable – it provides food.

Nigerian example: A Nigerian team always asks, "What value does this bring to our users?"

Illustration:

  Valuable = Adds value to the user or business
      

Mini summary: A valuable story delivers something useful to the user.


Lesson 7: E – Estimable

Definition: A story should be estimable – the team should be able to estimate how much effort it will take.

Why it is important: If you can't estimate it, you can't plan it.

Simple explanation: It's like knowing how long it takes to bake a cake – you need a rough idea.

Real-life example: A team can estimate a login feature takes 2 days.

School example: A student can estimate it takes 3 hours to write an essay.

Home example: You can estimate it takes 1 hour to clean the kitchen.

Nigerian example: A Nigerian team uses story points to estimate their stories.

Illustration:

  Estimable = Can be estimated for effort
      

Mini summary: Estimable stories can be planned and scheduled.


Lesson 8: S – Small

Definition: A story should be small enough to be completed in one Sprint.

Why it is important: Small stories are easier to deliver and get feedback on.

Simple explanation: It's like eating a pizza one slice at a time – it's easier than eating the whole pizza at once.

Real-life example: A feature that takes 2 days is small; a feature that takes 2 months is too big.

School example: Completing one chapter is small; completing the whole textbook is big.

Home example: Cleaning one room is small; cleaning the whole house is big.

Nigerian example: A Nigerian team breaks big features into small stories.

Illustration:

  Small = Can be completed in one Sprint
      

Mini summary: Small stories are easier to complete and deliver.


Lesson 9: T – Testable

Definition: A story should be testable – you should be able to prove that it works.

Why it is important: If you can't test it, you can't be sure it's done.

Simple explanation: It's like baking a cake – you can test it by tasting it.

Real-life example: A login feature is testable – you can try logging in to see if it works.

School example: A math problem is testable – you can check the answer.

Home example: A cleaned room is testable – you can check if it's tidy.

Nigerian example: A Nigerian team writes testable acceptance criteria.

Illustration:

  Testable = Can be tested to confirm it works
      

Mini summary: Testable stories can be verified to ensure they work.


Lesson 10: Acceptance Criteria – What "Done" Looks Like

Definition: Acceptance criteria are a list of conditions that must be met for a user story to be considered "done".

Why it is important: They give the team a clear target and prevent misunderstandings.

Simple explanation: It's like a checklist for finishing a task – you check off each item.

Real-life example: For a login feature: "User can enter email and password, user can click login, and user sees their dashboard."

School example: For an essay: "Has an introduction, 3 body paragraphs, and a conclusion."

Home example: For cleaning a room: "Bed is made, floor is vacuumed, and surfaces are dusted."

Nigerian example: A Nigerian team writes acceptance criteria like: "The app works on Android and iOS."

Illustration:

  Acceptance Criteria:
  - [ ] Condition 1
  - [ ] Condition 2
  - [ ] Condition 3
      

Mini summary: Acceptance criteria define what "done" means for a story.


Lesson 11: Writing Acceptance Criteria – Gherkin Format

Definition: Gherkin is a format for writing acceptance criteria that uses "Given", "When", "Then" to describe behaviour.

Why it is important: It's clear, structured, and easy to test.

Simple explanation: It's like a recipe – Given the ingredients, When you cook, Then you get the dish.

Real-life example: Given I am on the login page, When I enter correct credentials, Then I see my dashboard.

School example: Given I have studied the chapter, When I take the test, Then I pass.

Home example: Given I have cleaned the room, When my parent checks, Then they are happy.

Nigerian example: A Nigerian team uses Gherkin for clear acceptance criteria.

Illustration:

  Given [condition]
  When [action]
  Then [result]
      

Mini summary: Gherkin is a structured way to write acceptance criteria.


Lesson 12: Backlog Refinement – Keeping the Backlog Healthy

Definition: Backlog refinement is the process of reviewing, prioritising, and updating the Product Backlog to ensure it's ready for future Sprints.

Why it is important: It keeps the backlog clean and ensures the team always has ready-to-work stories.

Simple explanation: It's like pruning a garden – you remove dead leaves and organise the plants.

Real-life example: The Product Owner and team meet to review the backlog, add new stories, and reprioritise.

School example: A student reviews their to-do list and decides what to do next.

Home example: A family reviews their chore list and updates it.

Nigerian example: A Nigerian team holds a backlog refinement session every week.

Illustration:

  Backlog Refinement = Keeping the backlog clean and ready
      

Mini summary: Backlog refinement keeps the Product Backlog organised and ready.


Lesson 13: Who Participates in Backlog Refinement?

Definition: Backlog refinement involves the Product Owner, Scrum Master, and Development Team. Sometimes stakeholders join too.

Why it is important: Everyone needs to be aligned on the backlog.

Simple explanation: It's like a team meeting to plan the next game.

Real-life example: The team meets for 1 hour to review the top 10 stories.

School example: A study group meets to decide what topics to cover next.

Home example: A family meeting to plan the weekend tasks.

Nigerian example: A Nigerian team holds a refinement session with remote members joining via video call.

Illustration:

  Backlog Refinement Participants:
  Product Owner + Scrum Master + Development Team
      

Mini summary: Backlog refinement is a team effort involving the Product Owner, Scrum Master, and Development Team.


Lesson 14: Estimating User Stories – Story Points

Definition: Story points are a unit of measurement for estimating the effort of a user story. They are relative, not absolute.

Why it is important: They help the team plan how much work they can do in a Sprint.

Simple explanation: It's like using "small", "medium", "large" to describe how much work something is.

Real-life example: A simple story might be 1 point, a complex one might be 8 points.

School example: A short homework assignment is 1 point, a long project is 8 points.

Home example: Washing dishes is 1 point, cleaning the entire house is 8 points.

Nigerian example: A Nigerian team uses the Fibonacci sequence (1,2,3,5,8,13) for story points.

Illustration:

  Story Points:
  1 = Very small
  2 = Small
  3 = Medium
  5 = Large
  8 = Very large
      

Mini summary: Story points are a relative way to estimate effort.


Lesson 15: Planning Poker – A Fun Way to Estimate

Definition: Planning Poker is a game where team members use cards to estimate story points. Everyone shows their cards at the same time.

Why it is important: It encourages discussion and helps the team reach a consensus.

Simple explanation: It's like a game where everyone guesses a number and then discusses why they chose it.

Real-life example: The team reads a story, each member selects a card (1,2,3,5,8), and they discuss differences.

School example: A study group estimates how long a topic will take to learn – they discuss and agree.

Home example: A family estimates how long a task will take – they discuss and agree.

Nigerian example: A Nigerian team uses online planning poker tools for remote estimation.

Illustration:

  Planning Poker Cards:
  [1] [2] [3] [5] [8] [13] [20]
      

Mini summary: Planning Poker is a fun, collaborative way to estimate user stories.


Key Vocabulary (simple definitions)

  • User Story: A short description of a feature from a user's perspective.
  • Invest: A checklist for good user stories – Independent, Negotiable, Valuable, Estimable, Small, Testable.
  • Acceptance Criteria: A list of conditions for a story to be "done".
  • Gherkin: A format for writing acceptance criteria: Given/When/Then.
  • Backlog Refinement: The process of keeping the Product Backlog organised.
  • Story Points: A relative measure of effort for a user story.
  • Planning Poker: A game for estimating story points.

Important Concepts

  • User focus: User stories always start with the user.
  • Clear expectations: Acceptance criteria ensure everyone knows what "done" means.
  • Continuous refinement: The backlog is never "done" – it's always being refined.
  • Team collaboration: Estimation and refinement are team activities.

Step-by-Step Explanations

How to Write a User Story

  1. Identify the user (who will use this feature?).
  2. Describe the action (what do they want to do?).
  3. State the benefit (why do they want it?).
  4. Write it in the format: "As a [user], I want [action] so that [benefit]."
  5. Add acceptance criteria to define "done".

How to Run a Backlog Refinement Session

  1. Gather the Product Owner, Scrum Master, and Development Team.
  2. Review the top items on the Product Backlog.
  3. Discuss each story – clarify, split, or reprioritise.
  4. Add new stories if needed.
  5. Estimate stories using story points and planning poker.

Teacher Notes

  • Use the market woman story to show how user stories come from real people.
  • Encourage students to write user stories for everyday problems.
  • Teach INVEST as a checklist – not a strict rule.
  • Make backlog refinement interactive – simulate a session.

Parent Tips

  • Help your child practice writing user stories for chores or projects.
  • Use acceptance criteria to define what "done" means for tasks.
  • Encourage them to think about who the user is.

Interesting Facts & Did You Know?

  • Did you know? The user story format was created by Ron Jeffries, one of the creators of Extreme Programming.
  • Interesting: Some teams use the "Job Story" format instead of user stories: "When [situation], I want to [action], so I can [benefit]."
  • Did you know? The INVEST acronym was invented by Bill Wake.
  • Nigeria: Nigerian teams are increasingly using user stories to improve communication with clients.

Remember This

  • User stories are written from the user's perspective.
  • Use the format: As a... I want... So that...
  • INVEST helps you write good stories.
  • Acceptance criteria define what "done" means.
  • Backlog refinement keeps your backlog ready.

Common Mistakes

  • Too vague: "As a user, I want the system to work." – this is not a good story.
  • Too big: A story that takes more than one Sprint is too big.
  • No acceptance criteria: The team doesn't know when it's done.
  • No user: "The system needs to do X" – who is the user?

Best Practices

  • Write stories from the user's perspective.
  • Keep stories small and testable.
  • Always include acceptance criteria.
  • Refine the backlog regularly.
  • Use story points and planning poker for estimation.

Illustrations & Diagrams

User Story Template

  β”Œβ”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”
  β”‚  User Story: [Title]                              β”‚
  β”‚  As a [user]                                      β”‚
  β”‚  I want [action]                                  β”‚
  β”‚  So that [benefit]                                β”‚
  β”‚                                                   β”‚
  β”‚  Acceptance Criteria:                             β”‚
  β”‚  - [ ] Condition 1                                β”‚
  β”‚  - [ ] Condition 2                                β”‚
  β””β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”˜
      

INVEST Checklist

  INVEST:
  βœ… Independent   – can be built separately
  βœ… Negotiable    – can be discussed and changed
  βœ… Valuable      – adds value to the user
  βœ… Estimable     – can be estimated
  βœ… Small         – can be done in one Sprint
  βœ… Testable      – can be tested
      

Comparison Tables

Good vs Bad User Stories

Good StoryBad Story
"As a student, I want to check my grades so I can know my progress.""The system must have a grade feature."
Small, specific, has a userVague, no user, no value

User Story vs Acceptance Criteria

User StoryAcceptance Criteria
What the user needsHow to confirm it works
As a... I want... So that...Checklist of conditions

End-of-Module Summary

Fantastic job! You have mastered the art of writing user stories and refining the backlog. You now know the "As a... I want... So that..." format, the INVEST criteria, and how to write acceptance criteria using Gherkin. You also understand the importance of backlog refinement and how to estimate stories using story points and planning poker. These skills are essential for any Agile developer. In the next module, we will learn about Kanban – another Agile framework that focuses on flow and visualising work. Keep going!

Frequently Asked Questions (10)

  1. What is a user story? A short description of a feature from the user's perspective.
  2. What is the format of a user story? As a [user], I want [action] so that [benefit].
  3. What does INVEST stand for? Independent, Negotiable, Valuable, Estimable, Small, Testable.
  4. What are acceptance criteria? A checklist for when a story is "done".
  5. What is Gherkin? A format: Given/When/Then.
  6. What is backlog refinement? Keeping the Product Backlog clean and ready.
  7. Who participates in backlog refinement? Product Owner, Scrum Master, and Development Team.
  8. What are story points? A relative measure of effort.
  9. What is planning poker? A game for estimating stories.
  10. Why are user stories important? They keep the focus on the user.

Review Questions (15)

  1. What is a user story?
  2. What is the format of a user story?
  3. What does the "I" in INVEST stand for?
  4. What does the "N" in INVEST stand for?
  5. What does the "V" in INVEST stand for?
  6. What does the "E" in INVEST stand for?
  7. What does the "S" in INVEST stand for?
  8. What does the "T" in INVEST stand for?
  9. What are acceptance criteria?
  10. What is the Gherkin format?
  11. What is backlog refinement?
  12. Who participates in backlog refinement?
  13. What are story points?
  14. What is planning poker?
  15. Why are user stories important?

Fill-in-the-Blank Exercises

  1. A user story is written as: As a [user], I want [action] so that [_______]. (benefit)
  2. INVEST stands for Independent, Negotiable, Valuable, Estimable, Small, and _______. (Testable)
  3. _______ criteria define what "done" means. (Acceptance)
  4. Gherkin uses the format: _______, When, Then. (Given)
  5. _______ refinement is the process of keeping the Product Backlog clean. (Backlog)
  6. _______ points are a relative measure of effort. (Story)

True or False Exercises

  1. A user story is written from the developer's perspective. (False)
  2. INVEST is a checklist for good user stories. (True)
  3. Acceptance criteria are optional. (False)
  4. Backlog refinement is done only once. (False)
  5. Story points are an absolute measure of time. (False)

Multiple Choice Questions (15)

  1. What is a user story?
    A) A long document
    B) A short description from the user's perspective
    C) A type of game
    Answer: B
  2. What is the user story format?
    A) As a user, I want...
    B) Given/When/Then
    C) Story points
    Answer: A
  3. What does "I" in INVEST stand for?
    A) Independent
    B) Interesting
    C) Important
    Answer: A
  4. What does "S" in INVEST stand for?
    A) Simple
    B) Small
    C) Smart
    Answer: B
  5. What are acceptance criteria?
    A) A checklist for "done"
    B) A list of tasks
    C) A type of story
    Answer: A
  6. What is the Gherkin format?
    A) Given/When/Then
    B) As a/I want/So that
    C) Plan/Do/Review
    Answer: A
  7. What is backlog refinement?
    A) Keeping the backlog organised
    B) Building the backlog
    C) Deleting the backlog
    Answer: A
  8. Who participates in backlog refinement?
    A) Product Owner, Scrum Master, Dev Team
    B) Only the Product Owner
    C) Only the developers
    Answer: A
  9. What are story points?
    A) A relative measure of effort
    B) A unit of time
    C) A type of story
    Answer: A
  10. What is planning poker?
    A) A game for estimating
    B) A game for writing stories
    C) A game for testing
    Answer: A
  11. What does "V" in INVEST stand for?
    A) Valuable
    B) Visible
    C) Vague
    Answer: A
  12. What does "E" in INVEST stand for?
    A) Estimable
    B) Easy
    C) Exact
    Answer: A
  13. What does "T" in INVEST stand for?
    A) Testable
    B) Time-bound
    C) Tractable
    Answer: A
  14. What is the benefit of user stories?
    A) They focus on the user
    B) They focus on the technology
    C) They focus on the process
    Answer: A
  15. What is the goal of backlog refinement?
    A) To have a ready backlog
    B) To finish all stories
    C) To delete all stories
    Answer: A

Matching Exercises

TermMeaning
1. User StoryA. Short description from user perspective
2. INVESTB. Checklist for good stories
3. Acceptance CriteriaC. Definition of "done"
4. Backlog RefinementD. Keeping the backlog organised
5. Story PointsE. Relative measure of effort

Answers: 1-A, 2-B, 3-C, 4-D, 5-E

Short Answer Questions

  1. What is a user story?
  2. Write a user story for a school project.
  3. What are acceptance criteria?
  4. What is backlog refinement and why is it important?

Scenario-based Exercises

  • Scenario 1: You are building a food delivery app. Write a user story for the "search by restaurant" feature.
  • Scenario 2: Your team has a story that is too big – it says "As a user, I want to manage my account." How would you break it down?
  • Scenario 3: The Product Backlog is messy and full of old stories. What process would you recommend?

Group Activity

In groups, pick a common problem (e.g., ordering food, booking a flight). Write 5 user stories and their acceptance criteria. Present to the class.

Individual Activity

Write a user story for a feature you would want in an app. Include acceptance criteria in Gherkin format.

Classroom Discussion Questions

  • Why is it important to write stories from the user's perspective?
  • What would happen if you didn't have acceptance criteria?
  • How often should you do backlog refinement?

Mini Project

Create a "User Story Cheat Sheet" poster for your classroom. Include the format, INVEST criteria, and acceptance criteria examples.

Practical Assignment

Find a product or app you use. Write 3 user stories for features you would like to see. Share them with the class.

Challenge Exercise

Research how a Nigerian company uses user stories. Write a short report on what you find.

Quiz Answers

Multiple Choice answers: 1-B, 2-A, 3-A, 4-B, 5-A, 6-A, 7-A, 8-A, 9-A, 10-A, 11-A, 12-A, 13-A, 14-A, 15-A.

True/False answers: 1-F, 2-T, 3-F, 4-F, 5-F.

Key Takeaways

  • User stories are written from the user's perspective.
  • The format is: As a... I want... So that...
  • INVEST helps you write good stories.
  • Acceptance criteria define "done".
  • Backlog refinement keeps the backlog ready.
  • Story points and planning poker help with estimation.

Preparation for the Next Module

In Module 4, we will learn about Kanban – another Agile framework that focuses on visualising work and optimising flow. You will learn about Kanban boards, WIP limits, and how to manage work in progress. Get ready to visualise your work!

5

Module Four

Module 4: Kanban – Visualising Flow

Module Four: Kanban – Visualising Flow for Smooth Delivery

Module Introduction

Hello, flow master! πŸš€ In the last three modules, you learned about Agile, Scrum, and user stories. Now we are going to explore Kanban – a super visual way to manage work. Kanban is like a whiteboard where you can see every task, its status, and who is working on it. It helps teams work smoothly and finish things faster. You'll learn how to use a Kanban board, set Work In Progress (WIP) limits, and measure your flow. Let's get visual!

Learning Objectives

By the end of this module, you will be able to:

  • Explain what Kanban is and how it works.
  • Create and use a Kanban board.
  • Understand and apply WIP limits.
  • Measure flow using cycle time and throughput.
  • Compare Kanban with Scrum.

Warm-up Story: The Busy Workshop

In a busy workshop in Lagos, there was a team of mechanics. They had many cars to fix, but cars kept piling up. The manager, Mr. Ade, put up a big whiteboard. He divided it into columns: "To Do", "In Progress", and "Done". Every car repair was written on a sticky note and placed in the "To Do" column. When a mechanic started working on a car, they moved the note to "In Progress". When it was done, they moved it to "Done". Now everyone could see what was happening. They also limited the number of cars they worked on at the same time. Cars started flowing through the workshop faster, and customers were happier. That is Kanban!

Main Lessons

Lesson 1: What is Kanban?

Definition: Kanban is a visual way to manage work. It uses a board with columns that show the status of tasks.

Why it is important: It helps teams see what is happening, spot problems, and improve flow.

Simple explanation: It's like a to-do list on a whiteboard, where you can see every task and where it is.

Real-life example: A software team uses a Kanban board with columns: Backlog, In Progress, Review, Done.

School example: A student uses a board to track homework: To Do, Doing, Done.

Home example: A family uses a board to track chores: To Do, In Progress, Done.

Nigerian example: A Nigerian startup uses a Trello board (a digital Kanban) to track their product development.

Illustration:

  Kanban Board:
  β”Œβ”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”¬β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”¬β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”
  β”‚  To Do   β”‚ In Progress β”‚   Done   β”‚
  β”œβ”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”Όβ”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”Όβ”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€
  β”‚ Task A   β”‚  Task C    β”‚ Task B   β”‚
  β”‚ Task D   β”‚  Task E    β”‚ Task F   β”‚
  β””β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”΄β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”΄β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”˜
      

Mini summary: Kanban is a visual way to manage work using a board with columns.


Lesson 2: Where Did Kanban Come From?

Definition: Kanban was invented by Toyota in Japan to improve car manufacturing. It means "visual signal" in Japanese.

Why it is important: It started in factories and now is used in software and many other fields.

Simple explanation: It's like a traffic light for work – it tells you when to stop or go.

Real-life example: Toyota used Kanban cards to signal when to order more parts.

School example: A teacher uses a visual chart to show when students need help.

Home example: A parent uses a visual chore chart.

Nigerian example: A Nigerian manufacturing company uses Kanban to manage inventory.

Illustration:

  Kanban (Japanese) = Visual Signal
      

Mini summary: Kanban started in Toyota factories to improve manufacturing flow.


Lesson 3: The Kanban Board – Your Visual Tool

Definition: A Kanban board is a visual tool with columns that represent the stages of work.

Why it is important: It makes work visible and helps teams see bottlenecks.

Simple explanation: It's like a giant whiteboard where you can see every task and its status.

Real-life example: A team has columns: To Do, In Progress, Testing, Done.

School example: A student has columns: Not Started, Working, Finished.

Home example: A family has columns: To Do, Doing, Done.

Nigerian example: A Nigerian agency uses a physical Kanban board in their office.

Illustration:

  Kanban Board Columns:
  Backlog β†’ To Do β†’ In Progress β†’ Review β†’ Done
      

Mini summary: A Kanban board is a visual tool that shows the flow of work.


Lesson 4: The Four Principles of Kanban

Definition: The four principles of Kanban guide how you use it: Start with what you do now, agree to pursue change, respect current roles, and encourage leadership at all levels.

Why it is important: They help you implement Kanban smoothly without disrupting your team.

Simple explanation: It's like changing a recipe slowly – you don't change everything at once.

Real-life example: A team starts with their current process and slowly adds Kanban.

School example: A student starts with their current study method and slowly improves it.

Home example: A family starts with their current chores and slowly improves the system.

Nigerian example: A Nigerian team starts with a simple board and gradually adds WIP limits.

Illustration:

  4 Principles:
  1. Start with what you do now
  2. Agree to pursue change
  3. Respect current roles
  4. Encourage leadership at all levels
      

Mini summary: The four principles help you adopt Kanban smoothly.


Lesson 5: WIP Limits – Stop Overloading Your Team

Definition: WIP stands for Work In Progress. WIP limits are rules that limit how many tasks can be in a column at one time.

Why it is important: They prevent teams from taking on too much and help them finish tasks faster.

Simple explanation: It's like telling a chef to only cook 3 dishes at a time – so they can focus and cook well.

Real-life example: A team sets a WIP limit of 3 in the "In Progress" column – so they never work on more than 3 tasks at once.

School example: A student limits themselves to studying 2 subjects per day.

Home example: A family limits themselves to 2 chores per person per day.

Nigerian example: A Nigerian team sets WIP limits to avoid multitasking.

Illustration:

  WIP Limit: 3
  β”Œβ”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”
  β”‚ In Progressβ”‚ (max 3)
  β”œβ”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€
  β”‚ Task 1     β”‚
  β”‚ Task 2     β”‚
  β”‚ Task 3     β”‚
  β””β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”˜
      

Mini summary: WIP limits prevent overload and help teams finish tasks faster.


Lesson 6: Pull vs Push – How Work Moves

Definition: In Kanban, work is "pulled" – it only moves to the next stage when there is capacity. In "push" systems, work is forced onto the next stage.

Why it is important: Pull systems reduce waste and create smoother flow.

Simple explanation: It's like a restaurant – the kitchen only starts cooking when an order comes in (pull), not before.

Real-life example: A team only pulls a new task from the backlog when someone is free.

School example: A student only starts a new assignment when they finish the current one.

Home example: A family only starts a new chore when the current one is done.

Nigerian example: A Nigerian team uses a pull system to balance their workload.

Illustration:

  Push: Work is forced onto the next stage.
  Pull: Work is pulled when there is capacity.
      

Mini summary: In Kanban, work is pulled – it moves only when there's capacity.


Lesson 7: Cycle Time – How Long Does It Take?

Definition: Cycle time is the time it takes for a task to go from start to finish.

Why it is important: It tells you how fast your team is delivering.

Simple explanation: It's like measuring how long it takes to bake a cake – from the time you start to the time it's done.

Real-life example: A team measures that it takes 2 days on average to complete a task.

School example: A student measures how long it takes to finish an assignment.

Home example: A parent measures how long it takes to clean the kitchen.

Nigerian example: A Nigerian team tracks cycle time to improve their delivery speed.

Illustration:

  Cycle Time = Time from start to finish
  Example: Start on Monday, finish on Wednesday = 2 days cycle time
      

Mini summary: Cycle time measures how long it takes to complete a task.


Lesson 8: Throughput – How Much Do You Deliver?

Definition: Throughput is the number of tasks completed in a given time period (e.g., per week).

Why it is important: It measures your team's productivity.

Simple explanation: It's like counting how many cakes you bake in a week.

Real-life example: A team completes 10 tasks per week – that's their throughput.

School example: A student completes 5 assignments per month.

Home example: A family completes 3 chores per day.

Nigerian example: A Nigerian team measures their throughput to plan capacity.

Illustration:

  Throughput = Number of tasks completed in a period
  Example: 10 tasks per week = throughput of 10/week
      

Mini summary: Throughput measures how many tasks you complete in a given time.


Lesson 9: Cumulative Flow Diagram – Seeing the Big Picture

Definition: A Cumulative Flow Diagram (CFD) is a graph that shows how tasks move through the system over time.

Why it is important: It helps you spot bottlenecks and trends.

Simple explanation: It's like a weather chart for your work – you can see if it's getting better or worse.

Real-life example: A team looks at the CFD to see if tasks are piling up in a certain column.

School example: A student tracks their progress on different subjects.

Home example: A family tracks how long chores stay in "In Progress".

Nigerian example: A Nigerian team uses a CFD in their dashboard.

Illustration:

  Cumulative Flow Diagram (simplified):
  Tasks
    ↑
    β”‚  To Do: 5
    β”‚  In Progress: 3
    β”‚  Done: 10
    └────────────────→ Time
      

Mini summary: A Cumulative Flow Diagram shows how tasks flow over time.


Lesson 10: Kanban vs Scrum – Which One to Use?

Definition: Kanban and Scrum are both Agile frameworks. Kanban is continuous and focuses on flow. Scrum is iterative and uses fixed-length Sprints.

Why it is important: You need to choose the right framework for your team.

Simple explanation: Kanban is like a river that flows continuously. Scrum is like a series of sprints with breaks in between.

Real-life example: A support team uses Kanban because work comes in randomly. A product team uses Scrum for new features.

School example: A study group uses Kanban for ongoing learning. A project team uses Scrum for a big project.

Home example: A family uses Kanban for daily chores. They use Scrum for planning a big event.

Nigerian example: A Nigerian maintenance team uses Kanban. A product development team uses Scrum.

Illustration:

  Kanban: Continuous flow, no Sprints
  Scrum: Fixed-length Sprints, iterative
      

Mini summary: Kanban is continuous; Scrum is iterative. Choose based on your needs.


Lesson 11: When to Use Kanban

Definition: Kanban is best for teams that have continuous, unpredictable work – like support, maintenance, or operations.

Why it is important: It handles incoming work flexibly without fixed Sprints.

Simple explanation: It's like a busy emergency room – you don't know what will come in, but you need to handle it.

Real-life example: An IT support team uses Kanban to handle incoming tickets.

School example: A teacher uses Kanban to handle student questions and tasks.

Home example: A parent uses Kanban for daily chores.

Nigerian example: A Nigerian customer service team uses Kanban for support tickets.

Illustration:

  When to Use Kanban:
  - Unpredictable work
  - Continuous flow needed
  - Support, maintenance, operations
      

Mini summary: Kanban works best for continuous, unpredictable work.


Lesson 12: When to Use Scrum

Definition: Scrum is best for teams building new products or features with defined goals and deadlines.

Why it is important: It provides a clear structure for planning and delivering in fixed increments.

Simple explanation: It's like building a house – you have a plan, and you work in stages.

Real-life example: A product development team uses Scrum to build a new app.

School example: A student uses Scrum for a semester-long project.

Home example: A family uses Scrum to plan a big celebration.

Nigerian example: A Nigerian fintech uses Scrum to build new features.

Illustration:

  When to Use Scrum:
  - Building new products
  - Fixed goals and deadlines
  - Team can plan in Sprints
      

Mini summary: Scrum works best for building new products with fixed goals.


Lesson 13: Combining Kanban and Scrum – Scrumban

Definition: Scrumban is a hybrid that combines the structure of Scrum with the flow of Kanban.

Why it is important: It gives you the best of both worlds – planning and flexibility.

Simple explanation: It's like having a meal plan (Scrum) but being flexible with ingredients (Kanban).

Real-life example: A team uses Scrum planning but Kanban board for daily work.

School example: A student has a weekly plan but adapts daily based on workload.

Home example: A family has a monthly plan but adjusts daily.

Nigerian example: A Nigerian team uses Scrumban to balance structure and flexibility.

Illustration:

  Scrumban = Scrum + Kanban
      

Mini summary: Scrumban combines Scrum and Kanban for flexibility and structure.


Lesson 14: Kanban in Action – A Day in the Life

Definition: This lesson shows how a team uses Kanban daily – moving tasks, reviewing the board, and improving flow.

Why it is important: It shows you the practical use of Kanban.

Simple explanation: It's like a morning routine – you check the board, plan your day, and move tasks.

Real-life example: Every morning, the team stands in front of the board, reviews tasks, and plans the day.

School example: A student checks their task board every morning.

Home example: A family checks the chore board at breakfast.

Nigerian example: A Nigerian team has a daily stand-up in front of their Kanban board.

Illustration:

  Daily Kanban Routine:
  1. Check the board
  2. Move completed tasks to "Done"
  3. Pull new tasks when capacity is free
  4. Identify any blockers
      

Mini summary: Teams use Kanban daily to manage their work and improve flow.


Lesson 15: The Future of Kanban – Digital Boards

Definition: Digital boards like Trello, Jira, and Asana bring Kanban online – making it easy for remote teams.

Why it is important: Many teams work remotely – digital boards help them stay connected.

Simple explanation: It's like a whiteboard but on your computer – you can use it from anywhere.

Real-life example: A remote team uses Trello to manage their tasks.

School example: A group uses a digital board to collaborate on a project.

Home example: A family uses a shared digital board for chores.

Nigerian example: A Nigerian team uses Jira to manage their software development.

Illustration:

  Digital Kanban Tools:
  - Trello
  - Jira
  - Asana
  - ClickUp
      

Mini summary: Digital boards make Kanban accessible for remote and distributed teams.


Key Vocabulary (simple definitions)

  • Kanban: A visual way to manage work using a board with columns.
  • Kanban Board: A board that shows tasks and their status.
  • WIP Limit: A limit on how many tasks can be in progress at once.
  • Pull: Work is pulled to the next stage when there is capacity.
  • Cycle Time: Time from start to finish for a task.
  • Throughput: Number of tasks completed in a period.
  • Cumulative Flow Diagram: A graph showing task flow over time.
  • Scrumban: A hybrid of Scrum and Kanban.

Important Concepts

  • Visualisation: Seeing your work makes it manageable.
  • Limiting Work: WIP limits prevent overload and improve focus.
  • Flow: The smooth movement of work from start to finish.
  • Continuous Improvement: Kanban encourages you to constantly improve your process.

Step-by-Step Explanations

How to Create a Kanban Board

  1. Draw a board with columns: "To Do", "In Progress", "Done".
  2. Add a "Backlog" column for future work.
  3. Write each task on a sticky note.
  4. Place the notes in the "To Do" column.
  5. Set WIP limits for each column (e.g., max 3 in "In Progress").
  6. Move notes as work progresses.

How to Measure Cycle Time

  1. Note the date and time when a task moves to "In Progress".
  2. Note the date and time when it moves to "Done".
  3. Calculate the difference – that is the cycle time.
  4. Average the cycle times of several tasks for a better picture.

Teacher Notes

  • Use the workshop story to introduce Kanban visually.
  • Have students create a physical or digital Kanban board.
  • Emphasise that WIP limits are about focus, not laziness.
  • Compare Kanban and Scrum to help students understand both.

Parent Tips

  • Help your child create a Kanban board for their homework.
  • Teach them to limit how many tasks they do at once.
  • Celebrate when tasks are moved to "Done".

Interesting Facts & Did You Know?

  • Did you know? Kanban was developed by Taiichi Ohno at Toyota in the 1940s.
  • Interesting: The word "Kanban" means "signboard" or "visual signal" in Japanese.
  • Did you know? Many hospitals use Kanban to manage patient flow.
  • Nigeria: Nigerian companies are increasingly using Kanban to improve efficiency.

Remember This

  • Kanban visualises work on a board.
  • WIP limits prevent overload.
  • Work is pulled, not pushed.
  • Cycle time and throughput measure flow.
  • Kanban is great for continuous, unpredictable work.

Common Mistakes

  • No WIP limits: The team takes on too much and slows down.
  • Too many columns: Keep it simple – 3-5 columns is enough.
  • Not updating the board: The board must be updated in real-time.
  • Forgetting to measure: Without metrics, you can't improve.

Best Practices

  • Use a simple board with clear columns.
  • Set WIP limits and stick to them.
  • Update the board every day.
  • Measure cycle time and throughput.
  • Hold regular reviews to improve flow.

Illustrations & Diagrams

A Simple Kanban Board

  β”Œβ”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”¬β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”¬β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”¬β”€β”€β”€β”€β”€β”€β”€β”€β”€β”
  β”‚  Backlog  β”‚   To Do     β”‚In Progressβ”‚  Done   β”‚
  β”œβ”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”Όβ”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”Όβ”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”Όβ”€β”€β”€β”€β”€β”€β”€β”€β”€β”€
  β”‚  Story 1  β”‚  Task 5     β”‚  Task 2   β”‚ Task 3  β”‚
  β”‚  Story 2  β”‚  Task 6     β”‚  Task 4   β”‚ Task 7  β”‚
  β”‚           β”‚             β”‚           β”‚         β”‚
  β”‚           β”‚ WIP: 3      β”‚ WIP: 2    β”‚         β”‚
  β””β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”΄β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”΄β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”΄β”€β”€β”€β”€β”€β”€β”€β”€β”€β”˜
      

Cycle Time and Throughput

  Cycle Time = Time from start to finish
  Throughput = Tasks completed per week
      

Comparison Tables

Kanban vs Scrum

KanbanScrum
Continuous flowFixed Sprints
No roles definedProduct Owner, Scrum Master
WIP limitsSprint backlog
Pull systemSprint commitment
Best for support, opsBest for product development

When to Use Kanban vs Scrum

Use Kanban WhenUse Scrum When
Work is unpredictableWork can be planned
Continuous deliveryFixed releases
Support, maintenanceNew product development

End-of-Module Summary

Incredible work! You have mastered Kanban – the visual way to manage work. You learned how to create a Kanban board, set WIP limits, and understand flow using cycle time and throughput. You also learned the differences between Kanban and Scrum, and when to use each one. Kanban is a powerful tool for any team – it makes work visible and helps you deliver faster. In Module 5, we will dive into Extreme Programming (XP) – a set of engineering practices that make Agile teams even more awesome. Keep the flow going!

Frequently Asked Questions (10)

  1. What is Kanban? A visual way to manage work.
  2. What is a Kanban board? A board with columns showing task status.
  3. What is a WIP limit? A limit on tasks in progress.
  4. What is a pull system? Work is pulled when there is capacity.
  5. What is cycle time? Time from start to finish.
  6. What is throughput? Tasks completed per period.
  7. What is a Cumulative Flow Diagram? A graph showing task flow over time.
  8. What is the difference between Kanban and Scrum? Kanban is continuous; Scrum uses Sprints.
  9. When should I use Kanban? For continuous, unpredictable work.
  10. What is Scrumban? A hybrid of Scrum and Kanban.

Review Questions (15)

  1. What is Kanban?
  2. What is a Kanban board?
  3. What does WIP stand for?
  4. What is a WIP limit?
  5. What is a pull system?
  6. What is cycle time?
  7. What is throughput?
  8. What is a Cumulative Flow Diagram?
  9. What are the four principles of Kanban?
  10. What is the difference between Kanban and Scrum?
  11. When should you use Kanban?
  12. When should you use Scrum?
  13. What is Scrumban?
  14. What tools can you use for digital Kanban?
  15. Why is Kanban important?

Fill-in-the-Blank Exercises

  1. _______ is a visual way to manage work. (Kanban)
  2. A Kanban board has _______ that show task status. (columns)
  3. WIP stands for Work In _______. (Progress)
  4. _______ limits prevent overload. (WIP)
  5. _______ time is the time from start to finish. (Cycle)
  6. _______ is the number of tasks completed per period. (Throughput)

True or False Exercises

  1. Kanban uses fixed Sprints. (False)
  2. WIP limits help teams focus. (True)
  3. In Kanban, work is pushed to the next stage. (False)
  4. Cycle time measures how long a task takes. (True)
  5. Kanban is only for software teams. (False)

Multiple Choice Questions (15)

  1. What is Kanban?
    A) A game
    B) A visual way to manage work
    C) A type of food
    Answer: B
  2. What does WIP stand for?
    A) Work In Progress
    B) Work In Planning
    C) Work In Production
    Answer: A
  3. What is a WIP limit?
    A) A limit on tasks in progress
    B) A limit on tasks done
    C) A limit on tasks to do
    Answer: A
  4. What is a pull system?
    A) Work is pulled when capacity is free
    B) Work is pushed to the next stage
    C) Work is done randomly
    Answer: A
  5. What is cycle time?
    A) Time from start to finish
    B) Number of tasks per week
    C) Time to start a task
    Answer: A
  6. What is throughput?
    A) Tasks completed per period
    B) Time to complete a task
    C) Number of tasks in progress
    Answer: A
  7. What is a Cumulative Flow Diagram?
    A) A graph showing task flow
    B) A list of tasks
    C) A type of board
    Answer: A
  8. What is the difference between Kanban and Scrum?
    A) Kanban is continuous; Scrum uses Sprints
    B) They are the same
    C) Scrum is continuous
    Answer: A
  9. When should you use Kanban?
    A) For continuous, unpredictable work
    B) For fixed projects
    C) For new products
    Answer: A
  10. When should you use Scrum?
    A) For building new products
    B) For support tickets
    C) For daily chores
    Answer: A
  11. What is Scrumban?
    A) A hybrid of Scrum and Kanban
    B) A type of Scrum
    C) A type of Kanban
    Answer: A
  12. What is a Kanban board?
    A) A board with columns showing task status
    B) A list of tasks
    C) A type of report
    Answer: A
  13. Why are WIP limits important?
    A) To prevent overload
    B) To increase work
    C) To make it harder
    Answer: A
  14. What is the origin of Kanban?
    A) Toyota in Japan
    B) Google in USA
    C) A Nigerian company
    Answer: A
  15. What is the main goal of Kanban?
    A) To improve flow
    B) To complete all tasks at once
    C) To delay work
    Answer: A

Matching Exercises

TermMeaning
1. KanbanA. Visual work management
2. WIPB. Work In Progress
3. Cycle TimeC. Time from start to finish
4. ThroughputD. Tasks completed per period
5. PullE. Work moves when capacity is free

Answers: 1-A, 2-B, 3-C, 4-D, 5-E

Short Answer Questions

  1. What is Kanban?
  2. What is a WIP limit and why is it useful?
  3. What is the difference between cycle time and throughput?
  4. When would you use Kanban instead of Scrum?

Scenario-based Exercises

  • Scenario 1: Your team is always overloaded with tasks. How would Kanban help?
  • Scenario 2: You work in a support team with unpredictable incoming tickets. Which framework would you use and why?
  • Scenario 3: Your team wants to visualise their workflow. What would you suggest?

Group Activity

In groups, create a physical or digital Kanban board for a project (like planning a school event). Use columns, WIP limits, and move tasks during the session.

Individual Activity

Create a Kanban board for your personal tasks for the next week. Include columns, WIP limits, and track your cycle time.

Classroom Discussion Questions

  • What would happen if you didn't have WIP limits?
  • How can Kanban help you in your daily life?
  • Which framework do you prefer – Kanban or Scrum? Why?

Mini Project

Create a "Kanban Guide" poster for your classroom. Include what it is, how to set it up, and tips for using it effectively.

Practical Assignment

Set up a digital Kanban board using Trello or Jira. Add tasks, set WIP limits, and track your work for one week. Write a short report on what you learned.

Challenge Exercise

Research how a Nigerian company uses Kanban. Write a summary of what you find and share with the class.

Quiz Answers

Multiple Choice answers: 1-B, 2-A, 3-A, 4-A, 5-A, 6-A, 7-A, 8-A, 9-A, 10-A, 11-A, 12-A, 13-A, 14-A, 15-A.

True/False answers: 1-F, 2-T, 3-F, 4-T, 5-F.

Key Takeaways

  • Kanban visualises work on a board with columns.
  • WIP limits prevent overload and improve focus.
  • Work is pulled, not pushed.
  • Cycle time and throughput measure flow.
  • Kanban is great for continuous, unpredictable work.
  • Digital tools make Kanban accessible for remote teams.

Preparation for the Next Module

In Module 5, we will explore Extreme Programming (XP) – a set of engineering practices that make teams even better at building quality software. You'll learn about Test-Driven Development (TDD), Pair Programming, Continuous Integration, and more. Get ready to code like a pro!

6

Module Five

Module 5: Extreme Programming (XP) – Engineering Excellence

Module Five: Extreme Programming (XP) – Engineering Excellence

Module Introduction

Hello, code champion! πŸ’» In the last four modules, you learned about Agile, Scrum, user stories, and Kanban. Now we are going to dive into Extreme Programming (XP) – a set of engineering practices that make software development faster, better, and more fun. XP is like the "sports training" for developers – it includes practices like writing tests first (Test-Driven Development), working in pairs (Pair Programming), and integrating code continuously. By the end of this module, you'll have the skills to build high-quality software with confidence. Let's go!

Learning Objectives

By the end of this module, you will be able to:

  • Explain what Extreme Programming (XP) is.
  • Understand Test-Driven Development (TDD).
  • Apply Pair Programming effectively.
  • Implement Continuous Integration (CI).
  • Describe other XP practices like Refactoring and Collective Ownership.

Warm-up Story: The Jollof Rice Test

In a Nigerian kitchen, two chefs, Funke and Emeka, wanted to create the best Jollof rice. Funke said, "Let's write down the recipe first, then cook it all at once." Emeka said, "No – let's write the recipe as a test. We'll write down what the perfect Jollof should taste like, then cook small portions and test them until they match the recipe." They wrote a "test recipe" (like a test case). They cooked a small pot, tasted it, adjusted, and tested again. Each time they got closer to perfection. They delivered a perfect dish faster and with less waste. That's Test-Driven Development (TDD) – you write the test first, then build to pass it!

Main Lessons

Lesson 1: What is Extreme Programming (XP)?

Definition: Extreme Programming (XP) is a set of engineering practices that help teams build high-quality software quickly and respond to change.

Why it is important: XP focuses on technical excellence – it makes code clean, reliable, and easy to change.

Simple explanation: It's like the "pro" way of writing code – you test everything, you work together, and you keep things simple.

Real-life example: A team uses TDD, Pair Programming, and CI to build a new app.

School example: A group uses Pair Programming to solve math problems – one explains, the other writes.

Home example: Two family members cook together – one reads the recipe, the other does the cooking.

Nigerian example: A Nigerian startup uses XP practices to build reliable software.

Illustration:

  XP Practices:
  - TDD (Test-Driven Development)
  - Pair Programming
  - Continuous Integration
  - Refactoring
  - Collective Ownership
      

Mini summary: XP is a set of engineering practices for building high-quality software.


Lesson 2: Test-Driven Development (TDD) – Write the Test First

Definition: TDD is a practice where you write a test before you write the code. The test fails, then you write the code to make it pass.

Why it is important: It ensures your code works, reduces bugs, and gives you confidence to make changes.

Simple explanation: It's like saying, "I want the car to go 100 km/h" – then you build a car that can do that.

Real-life example: A developer writes a test that checks if a login function works – then writes the login code to pass the test.

School example: A student writes a practice test, then studies to be able to answer the questions.

Home example: You decide you want to bake a cake, so you find a recipe (the test), then you bake to match it.

Nigerian example: A Nigerian developer writes a test for a payment feature before building it.

Illustration:

  TDD Cycle:
  1. Write a test (it fails)
  2. Write the code (to pass the test)
  3. Refactor (clean up the code)
      

Mini summary: TDD means writing a test first, then building the code to pass it.


Lesson 3: Why TDD is Awesome

Definition: TDD is awesome because it reduces bugs, improves design, and gives you confidence to change code.

Why it is important: You can change your code without fear of breaking things – the tests will tell you.

Simple explanation: It's like having a safety net – you can try new things without falling.

Real-life example: A team refactors their code (improves it) and runs the tests to make sure everything still works.

School example: A student uses practice quizzes to test their knowledge before an exam.

Home example: You test a new recipe on a small scale before cooking for guests.

Nigerian example: A Nigerian fintech company uses TDD to ensure their app is reliable.

Illustration:

  Benefits of TDD:
  - Fewer bugs
  - Better design
  - Confidence to change code
      

Mini summary: TDD gives you confidence to change your code without breaking things.


Lesson 4: Pair Programming – Two Heads Are Better

Definition: Pair Programming is a practice where two developers work together at one computer. One is the "Driver" (types) and the other is the "Navigator" (reviews, thinks ahead).

Why it is important: It catches mistakes early, shares knowledge, and leads to better code.

Simple explanation: It's like having a co-pilot – one person flies, the other watches the map.

Real-life example: Two developers work together – one writes code, the other reviews and suggests improvements.

School example: Two students work on a math problem – one writes, the other checks.

Home example: Two people cook together – one cuts vegetables, the other stirs the pot.

Nigerian example: A Nigerian team uses Pair Programming to build a new feature.

Illustration:

  Pair Programming Roles:
  Driver: Writes the code
  Navigator: Reviews, thinks ahead, suggests improvements
      

Mini summary: Pair Programming means two people work together – one types, one reviews.


Lesson 5: Benefits of Pair Programming

Definition: Pair Programming leads to fewer bugs, faster problem-solving, and shared knowledge across the team.

Why it is important: It makes the team stronger because knowledge is shared, not siloed.

Simple explanation: It's like two people moving a heavy sofa – it's easier and faster.

Real-life example: Two developers find a bug faster together than alone.

School example: Two students solve a difficult problem faster together.

Home example: Two people clean a room faster than one.

Nigerian example: A Nigerian team uses Pair Programming to reduce errors.

Illustration:

  Benefits:
  - Fewer bugs
  - Faster problem-solving
  - Knowledge sharing
  - Better team morale
      

Mini summary: Pair Programming makes teams faster, smarter, and more connected.


Lesson 6: Continuous Integration (CI) – Merge Often

Definition: Continuous Integration is a practice where developers integrate their code into a shared repository several times a day. Every integration is verified by automated tests.

Why it is important: It catches integration problems early and keeps the codebase healthy.

Simple explanation: It's like regularly saving your game – you don't lose progress, and you know everything works.

Real-life example: A team uses a CI tool that automatically runs tests when code is pushed.

School example: A study group shares their notes daily to stay aligned.

Home example: A family shares updates regularly so everyone knows what's happening.

Nigerian example: A Nigerian team uses Jenkins or GitHub Actions for CI.

Illustration:

  CI Flow:
  Code β†’ Push β†’ Build β†’ Run Tests β†’ Notify if failed
      

Mini summary: Continuous Integration means integrating code often with automated tests.


Lesson 7: Benefits of Continuous Integration

Definition: CI gives fast feedback, reduces integration problems, and ensures a working codebase.

Why it is important: You don't have "integration hell" – problems are caught early.

Simple explanation: It's like checking your work as you go, not at the very end.

Real-life example: A team pushes code, tests run automatically, and everyone is notified if something fails.

School example: A student reviews their notes daily, not just before the exam.

Home example: A family checks the grocery list throughout the week, not just before shopping.

Nigerian example: A Nigerian team uses CI to catch bugs early.

Illustration:

  CI Benefits:
  - Fast feedback
  - Fewer integration problems
  - Always working codebase
      

Mini summary: CI gives fast feedback and keeps the codebase healthy.


Lesson 8: Refactoring – Improving Without Changing Behaviour

Definition: Refactoring is the process of improving the structure of code without changing its behaviour.

Why it is important: It keeps code clean, readable, and easy to maintain.

Simple explanation: It's like tidying your room – it looks better and you can find things easier, but the room is still a room.

Real-life example: A developer renames variables to make them clearer, but the code still works the same.

School example: A student rewrites their notes to be clearer, but the content is the same.

Home example: You reorganise your bookshelf – the books are the same, but easier to find.

Nigerian example: A Nigerian team refactors code to improve maintainability.

Illustration:

  Refactoring = Clean up code, keep behaviour the same
      

Mini summary: Refactoring makes code cleaner without changing what it does.


Lesson 9: Why Refactor?

Definition: Refactoring reduces complexity, makes code easier to understand, and makes it easier to add new features.

Why it is important: Code that is messy is hard to change – refactoring keeps it healthy.

Simple explanation: It's like cleaning your tools – they work better and last longer.

Real-life example: A team refactors code before adding a new feature to make it easier.

School example: A student reviews and improves their essay before submitting.

Home example: You organise your closet so you can find clothes faster.

Nigerian example: A Nigerian team refactors their codebase to improve performance.

Illustration:

  Refactoring Benefits:
  - Easier to understand
  - Easier to change
  - Fewer bugs
      

Mini summary: Refactoring keeps code clean and easy to work with.


Lesson 10: Collective Ownership – Everyone Owns the Code

Definition: Collective Ownership means everyone on the team can change any part of the code. No one owns a specific piece.

Why it is important: It prevents bottlenecks and encourages teamwork.

Simple explanation: It's like a communal garden – everyone can plant, water, and harvest.

Real-life example: Any team member can fix a bug or add a feature anywhere in the code.

School example: Any group member can add to any part of a project.

Home example: Any family member can wash any dish.

Nigerian example: A Nigerian team practices collective ownership to avoid silos.

Illustration:

  Collective Ownership = Everyone can change any code
      

Mini summary: Collective Ownership means everyone shares responsibility for the code.


Lesson 11: Simple Design – Keep It Simple

Definition: Simple Design means building only what is needed, not adding extra complexity.

Why it is important: Simple code is easier to understand, change, and test.

Simple explanation: It's like packing for a trip – you don't bring 10 pairs of shoes when you only need 1.

Real-life example: A team builds the simplest solution that works – they don't over-engineer.

School example: A student writes a clear, simple essay instead of a complicated one.

Home example: You buy only the groceries you need for the week.

Nigerian example: A Nigerian team follows YAGNI (You Aren't Gonna Need It) – they don't build features they don't need.

Illustration:

  Simple Design = Build what you need, nothing more
      

Mini summary: Simple Design means building just what is needed – no extra complexity.


Lesson 12: Planning Game – Prioritising Work

Definition: The Planning Game is a practice where the team and customer decide what stories to work on next.

Why it is important: It ensures the most important work is done first.

Simple explanation: It's like deciding which chores to do first – you pick the most important ones.

Real-life example: The team and Product Owner discuss priorities and plan the next iteration.

School example: A study group decides which subjects to study first based on the exam schedule.

Home example: A family decides which tasks to do first based on urgency.

Nigerian example: A Nigerian team uses the Planning Game to align on priorities.

Illustration:

  Planning Game:
  Customer says what is important β†’ Team estimates β†’ Plan
      

Mini summary: The Planning Game helps the team and customer agree on priorities.


Lesson 13: On-Site Customer – The Customer is There

Definition: On-Site Customer means the customer is available to the team to answer questions and clarify requirements.

Why it is important: It reduces miscommunication and speeds up decision-making.

Simple explanation: It's like having a teacher in the classroom to answer questions immediately.

Real-life example: The Product Owner sits with the team and answers questions daily.

School example: A teacher is available during class to help students.

Home example: A parent is available to answer questions while children do homework.

Nigerian example: A Nigerian team has a Product Owner who is always available.

Illustration:

  On-Site Customer = Customer is always available to the team
      

Mini summary: Having the customer nearby reduces misunderstandings.


Lesson 14: Continuous Improvement – Never Stop Getting Better

Definition: Continuous Improvement means the team always looks for ways to improve their processes and practices.

Why it is important: It's the engine of growth – teams that improve get better over time.

Simple explanation: It's like practicing a sport – you always try to get better.

Real-life example: A team holds a retrospective to discuss what to improve.

School example: A student reviews their study habits and changes them to get better grades.

Home example: A family discusses how to make chores more efficient.

Nigerian example: A Nigerian team has regular retrospectives to improve.

Illustration:

  Continuous Improvement = Always find ways to do better
      

Mini summary: Continuous Improvement means always looking for ways to get better.


Lesson 15: Putting It All Together – XP in Action

Definition: XP practices work together to create a smooth, high-quality development process.

Why it is important: Each practice supports the others – they are a complete system.

Simple explanation: It's like a sports team – each player has a role, and together they win.

Real-life example: A team uses TDD, Pair Programming, CI, and Refactoring every day.

School example: A study group uses multiple learning methods to improve.

Home example: A family uses routines and teamwork to manage daily life.

Nigerian example: A Nigerian team combines all XP practices for excellence.

Illustration:

  XP in Action:
  TDD β†’ Pair Programming β†’ CI β†’ Refactoring β†’ Repeat
      

Mini summary: XP practices work together to deliver high-quality software.


Key Vocabulary (simple definitions)

  • Extreme Programming (XP): A set of engineering practices for building high-quality software.
  • TDD: Test-Driven Development – writing tests before code.
  • Pair Programming: Two people coding together – one drives, one navigates.
  • CI: Continuous Integration – integrating code often with automated tests.
  • Refactoring: Improving code structure without changing behaviour.
  • Collective Ownership: Everyone can change any part of the code.
  • Simple Design: Building only what is needed.
  • Planning Game: Prioritising work with the customer.
  • On-Site Customer: Customer available to the team.
  • Continuous Improvement: Always finding ways to get better.

Important Concepts

  • Quality first: XP focuses on building quality into the process.
  • Collaboration: Pair Programming and Collective Ownership build strong teams.
  • Feedback: TDD, CI, and On-Site Customer provide fast feedback.
  • Simplicity: Simple Design and Refactoring keep code clean.

Step-by-Step Explanations

How to Do TDD

  1. Write a test for a new feature (it will fail).
  2. Write just enough code to make the test pass.
  3. Run the test – it should pass.
  4. Refactor the code to make it clean.
  5. Repeat for the next feature.

How to Do Pair Programming

  1. Choose two people – one is the Driver, one is the Navigator.
  2. Driver types the code.
  3. Navigator reviews the code, thinks about design, and suggests improvements.
  4. Switch roles every 20-30 minutes.
  5. Communicate constantly – explain what you're doing.

Teacher Notes

  • Use the Jollof rice story to make TDD relatable.
  • Encourage students to practice Pair Programming in class.
  • Show a simple TDD example on the board.
  • Discuss why CI is important for team projects.

Parent Tips

  • Help your child practice TDD with simple tasks – write a plan first, then execute.
  • Encourage them to work in pairs on school projects.
  • Teach them to refactor – improve their work without starting over.

Interesting Facts & Did You Know?

  • Did you know? XP was created by Kent Beck in the late 1990s.
  • Interesting: XP's practices were inspired by patterns from successful projects.
  • Did you know? Many of the world's top tech companies use XP practices.
  • Nigeria: Nigerian startups are adopting XP to improve software quality.

Remember This

  • XP is about engineering excellence.
  • TDD: test first, then code.
  • Pair Programming: two heads are better than one.
  • CI: integrate often, test automatically.
  • Refactoring: keep code clean.
  • Collective Ownership: everyone is responsible.

Common Mistakes

  • Not doing TDD: Writing code without tests leads to bugs.
  • Pair Programming with no communication: The navigator must be engaged.
  • Not running CI regularly: Integration problems pile up.
  • Ignoring refactoring: Code becomes messy and hard to change.

Best Practices

  • Write tests before code (TDD).
  • Pair Program with frequent role switching.
  • Integrate code daily with automated tests.
  • Refactor continuously.
  • Keep design simple and clean.

Illustrations & Diagrams

TDD Cycle

  Write Test β†’ Run Test (fails) β†’ Write Code β†’ Run Test (passes) β†’ Refactor
      

Pair Programming Setup

  Driver (typing)  ←  Navigator (reviewing, thinking)
      

Comparison Tables

XP vs Traditional Development

XP PracticeTraditional Practice
Write tests firstTest at the end
Pair ProgrammingIndividual work
Integrate dailyIntegrate at the end
Refactor continuouslyRarely refactor
Collective ownershipIndividual ownership

XP Practices Overview

PracticePurpose
TDDEnsure code works
Pair ProgrammingCollaborate and learn
CIPrevent integration problems
RefactoringKeep code clean
Collective OwnershipShare responsibility

End-of-Module Summary

Outstanding work! You have learned the key practices of Extreme Programming (XP). You now understand Test-Driven Development (TDD), Pair Programming, Continuous Integration, Refactoring, and Collective Ownership. These practices help teams build high-quality software, catch bugs early, and keep code clean and maintainable. XP is the "engineering" side of Agile – it makes sure the code is as good as the ideas. In Module 6, we will learn about Agile Estimation and Planning – how to estimate work and plan your Sprints effectively. Keep the quality high!

Frequently Asked Questions (10)

  1. What is XP? A set of engineering practices for building high-quality software.
  2. What is TDD? Test-Driven Development – writing tests before code.
  3. What is Pair Programming? Two people coding together.
  4. What is CI? Continuous Integration – integrating code often.
  5. What is Refactoring? Improving code structure without changing behaviour.
  6. What is Collective Ownership? Everyone can change any code.
  7. What is Simple Design? Building only what is needed.
  8. What is the Planning Game? Prioritising work with the customer.
  9. What is an On-Site Customer? Customer available to the team.
  10. What is Continuous Improvement? Always finding ways to get better.

Review Questions (15)

  1. What is Extreme Programming?
  2. What is TDD?
  3. What are the steps of TDD?
  4. What is Pair Programming?
  5. What are the roles in Pair Programming?
  6. What is Continuous Integration?
  7. Why is CI important?
  8. What is Refactoring?
  9. Why do we refactor?
  10. What is Collective Ownership?
  11. What is Simple Design?
  12. What is the Planning Game?
  13. What is an On-Site Customer?
  14. What is Continuous Improvement?
  15. How do XP practices work together?

Fill-in-the-Blank Exercises

  1. _______ is a set of engineering practices for building high-quality software. (XP)
  2. _______ means writing tests before code. (TDD)
  3. _______ is two people coding together. (Pair Programming)
  4. _______ means integrating code often with automated tests. (CI)
  5. _______ means improving code structure without changing behaviour. (Refactoring)
  6. _______ means everyone can change any code. (Collective Ownership)

True or False Exercises

  1. TDD means writing tests after code. (False)
  2. Pair Programming is two people working together. (True)
  3. CI helps catch integration problems early. (True)
  4. Refactoring changes the behaviour of the code. (False)
  5. Collective Ownership means only one person can change the code. (False)

Multiple Choice Questions (15)

  1. What does TDD stand for?
    A) Test-Driven Development
    B) Test-Driven Design
    C) Time-Driven Development
    Answer: A
  2. What is Pair Programming?
    A) Two people coding together
    B) One person coding
    C) No coding
    Answer: A
  3. What is CI?
    A) Continuous Integration
    B) Continuous Improvement
    C) Code Integration
    Answer: A
  4. What is Refactoring?
    A) Improving code structure
    B) Adding new features
    C) Deleting code
    Answer: A
  5. What is Collective Ownership?
    A) Everyone can change any code
    B) One person owns the code
    C) No one can change the code
    Answer: A
  6. What is Simple Design?
    A) Building only what is needed
    B) Building everything possible
    C) Building nothing
    Answer: A
  7. What is the Planning Game?
    A) Prioritising work with the customer
    B) A game for fun
    C) A type of code
    Answer: A
  8. What is an On-Site Customer?
    A) Customer available to the team
    B) Customer not available
    C) Customer is the developer
    Answer: A
  9. What is Continuous Improvement?
    A) Always finding ways to get better
    B) Never improving
    C) Improving once a year
    Answer: A
  10. What is the TDD cycle?
    A) Test β†’ Code β†’ Refactor
    B) Code β†’ Test β†’ Refactor
    C) Refactor β†’ Test β†’ Code
    Answer: A
  11. In Pair Programming, the Driver:
    A) Types the code
    B) Reviews the code
    C) Does nothing
    Answer: A
  12. In Pair Programming, the Navigator:
    A) Reviews and thinks ahead
    B) Types the code
    C) Does nothing
    Answer: A
  13. Why is CI important?
    A) Prevents integration problems
    B) Makes code slower
    C) Doesn't matter
    Answer: A
  14. Why do we refactor?
    A) To keep code clean
    B) To add bugs
    C) To make code worse
    Answer: A
  15. What is the goal of XP?
    A) High-quality software
    B) Fast but buggy software
    C) No software
    Answer: A

Matching Exercises

TermMeaning
1. TDDA. Write tests first
2. Pair ProgrammingB. Two people coding together
3. CIC. Integrate code often
4. RefactoringD. Improve code structure
5. Collective OwnershipE. Everyone can change code

Answers: 1-A, 2-B, 3-C, 4-D, 5-E

Short Answer Questions

  1. What is TDD?
  2. What is Pair Programming?
  3. What is CI and why is it important?
  4. What is the difference between Refactoring and adding new features?

Scenario-based Exercises

  • Scenario 1: Your team's code is full of bugs. Which XP practice would you recommend and why?
  • Scenario 2: A developer is struggling with a complex problem. How could Pair Programming help?
  • Scenario 3: Your team has integration problems – code doesn't work together. What practice would you suggest?

Group Activity

In groups, simulate a TDD cycle for a simple problem (e.g., a calculator function). Write a test, write the code, and refactor. Present to the class.

Individual Activity

Find a coding problem online. Write a test for it first (in pseudocode), then write the solution. Write a short reflection on the TDD experience.

Classroom Discussion Questions

  • Why do you think TDD is better than testing at the end?
  • Have you ever worked in pairs? How did it go?
  • What are the benefits of keeping code simple?

Mini Project

Create a poster that explains XP practices. Include TDD, Pair Programming, CI, Refactoring, and Collective Ownership.

Practical Assignment

Set up a simple CI pipeline (using a free tool like GitHub Actions) for a small project. Write a short report on how it works.

Challenge Exercise

Research how a Nigerian company uses XP practices. Write a summary and share with the class.

Quiz Answers

Multiple Choice answers: 1-A, 2-A, 3-A, 4-A, 5-A, 6-A, 7-A, 8-A, 9-A, 10-A, 11-A, 12-A, 13-A, 14-A, 15-A.

True/False answers: 1-F, 2-T, 3-T, 4-F, 5-F.

Key Takeaways

  • XP is a set of engineering practices for high-quality software.
  • TDD: test first, then code.
  • Pair Programming: two people coding together.
  • CI: integrate often with automated tests.
  • Refactoring: keep code clean.
  • Collective Ownership: everyone is responsible.

Preparation for the Next Module

In Module 6, we will learn about Agile Estimation and Planning – how to estimate work, plan Sprints, and manage your projects effectively. You'll learn about story points, velocity, and release planning. Get ready to plan like a pro!

7

Module Six

Module 6: Agile Estimation and Planning

Module Six: Agile Estimation and Planning – Predicting the Future

Module Introduction

Hello, future planner! πŸ—“οΈ In the last five modules, you learned about Agile, Scrum, user stories, Kanban, and XP. Now we are going to learn how to estimate and plan your work. Estimation is like predicting how long a task will take – but in Agile, we don't use hours. We use story points – a fun way to measure effort. Planning helps you decide what to do in each Sprint and when you will finish your product. By the end of this module, you'll be able to estimate stories, plan Sprints, and create release plans. Let's get planning!

Learning Objectives

By the end of this module, you will be able to:

  • Explain the difference between estimation and planning.
  • Use story points to estimate effort.
  • Understand and apply velocity.
  • Plan a Sprint using the Sprint Backlog.
  • Create a release plan.

Warm-up Story: The Market Day Planning

In a bustling village in Nigeria, there was a market day every Saturday. A young trader named Chidi had to plan how many crates of tomatoes to bring. He didn't count in kilos – he used "crates" as his unit. One crate could feed 10 people. He knew that he usually sold 5 crates on a normal day, but on a festival, he might sell 10. He planned his weekly trips accordingly. In Agile, we use "story points" instead of crates. We know our "velocity" – how many points we can do in a Sprint – and we plan based on that. That's exactly what Agile estimation is!

Main Lessons

Lesson 1: What is Estimation?

Definition: Estimation is predicting how much effort a task or feature will take to complete.

Why it is important: It helps the team plan what they can do in a Sprint.

Simple explanation: It's like guessing how long it will take to clean your room – you need a rough idea to plan your day.

Real-life example: A team estimates a login feature as 3 story points.

School example: A student estimates that an essay will take 3 hours.

Home example: You estimate that cooking dinner will take 1 hour.

Nigerian example: A Nigerian team estimates a mobile payment feature as 5 story points.

Illustration:

  Estimation = Predicting effort (not time!)
      

Mini summary: Estimation predicts the effort needed to complete a task.


Lesson 2: What is Planning?

Definition: Planning is deciding what work to do and when to do it – based on your estimates.

Why it is important: It helps the team stay focused and deliver on time.

Simple explanation: It's like making a weekly schedule – you decide what to do each day.

Real-life example: A team plans to build the login feature this Sprint.

School example: A student plans to study math on Monday and English on Tuesday.

Home example: A family plans to clean the house on Saturday.

Nigerian example: A Nigerian startup plans a Sprint with 5 stories.

Illustration:

  Planning = Deciding what to do and when
      

Mini summary: Planning uses estimates to decide what work to do.


Lesson 3: Story Points – The Agile Unit of Effort

Definition: Story points are a relative measure of effort – they are not hours or days.

Why it is important: They are more accurate than hours because they consider complexity, uncertainty, and effort.

Simple explanation: It's like using "small", "medium", "large" to describe how much work something is.

Real-life example: A simple story might be 1 point, a complex one might be 8 points.

School example: A short homework assignment is 1 point, a long project is 8 points.

Home example: Washing dishes is 1 point, cleaning the entire house is 8 points.

Nigerian example: A Nigerian team uses the Fibonacci sequence (1,2,3,5,8,13) for points.

Illustration:

  Story Points:
  1 = Very small
  2 = Small
  3 = Medium
  5 = Large
  8 = Very large
      

Mini summary: Story points are a relative measure of effort – not hours.


Lesson 4: Why Story Points, Not Hours?

Definition: Story points are better than hours because they are less affected by individual speed or interruptions.

Why it is important: Points are stable – they don't change if a different person works on the story.

Simple explanation: It's like saying a trip is "long" instead of "2 hours" – because traffic can change the time.

Real-life example: A story is 3 points whether a junior or senior developer works on it.

School example: An assignment is "medium" regardless of which student does it.

Home example: Cleaning the kitchen is a "medium" chore, no matter who does it.

Nigerian example: A Nigerian team uses points for consistent planning.

Illustration:

  Hours = Varies by person
  Story Points = Stable, team-based
      

Mini summary: Story points are stable and not affected by who does the work.


Lesson 5: The Fibonacci Sequence – A Simple Scale

Definition: The Fibonacci sequence (1,2,3,5,8,13) is a popular scale for story points because the gaps get larger as numbers get bigger.

Why it is important: It forces teams to think about the difference between a 3 and a 5 – they are quite different.

Simple explanation: It's like using "small", "medium", "large" – but with numbers.

Real-life example: A team uses 1,2,3,5,8,13 for their stories.

School example: A student grades their tasks as 1,2,3,5,8 based on difficulty.

Home example: A family rates chores on the Fibonacci scale.

Nigerian example: A Nigerian startup uses the Fibonacci scale for estimation.

Illustration:

  Fibonacci:
  1, 2, 3, 5, 8, 13, 21...
      

Mini summary: The Fibonacci scale helps teams estimate with a clear, increasing range.


Lesson 6: Velocity – How Fast Does Your Team Go?

Definition: Velocity is the average number of story points a team completes in a Sprint.

Why it is important: It helps the team predict how much they can do in future Sprints.

Simple explanation: It's like your running speed – if you run 5 km in 30 minutes, you can plan your next run.

Real-life example: A team completes 20 points in Sprint 1, 22 in Sprint 2 – their velocity is ~21 points.

School example: A student completes 3 assignments per week – that's their velocity.

Home example: A family cleans 5 rooms per week – that's their velocity.

Nigerian example: A Nigerian team uses velocity to plan their Sprints.

Illustration:

  Velocity = Average points per Sprint
      

Mini summary: Velocity is the average story points completed per Sprint.


Lesson 7: Calculating Velocity

Definition: To calculate velocity, add the points of all completed stories in a Sprint, then average over several Sprints.

Why it is important: It gives you a reliable number for planning.

Simple explanation: It's like calculating your average daily steps over a week.

Real-life example: Sprint 1: 20 points, Sprint 2: 22 points, Sprint 3: 18 points – average = 20 points.

School example: Week 1: 3 assignments, Week 2: 4, Week 3: 2 – average = 3.

Home example: Day 1: 5 chores, Day 2: 6, Day 3: 4 – average = 5.

Nigerian example: A Nigerian team uses their velocity to plan releases.

Illustration:

  Velocity = (Sprint 1 + Sprint 2 + Sprint 3) / 3
      

Mini summary: Velocity is the average points completed – it helps you plan.


Lesson 8: Sprint Planning – The Plan

Definition: Sprint Planning is the meeting where the team decides what stories to work on in the upcoming Sprint.

Why it is important: It sets the direction for the Sprint.

Simple explanation: It's like planning a weekly menu – you decide what to cook each day.

Real-life example: The team picks 5 stories from the backlog, totalling their velocity (e.g., 20 points).

School example: A student plans which assignments to complete this week.

Home example: A family plans which chores to do on the weekend.

Nigerian example: A Nigerian team holds Sprint Planning every 2 weeks.

Illustration:

  Sprint Planning:
  1. Decide Sprint Goal
  2. Select stories from backlog
  3. Break stories into tasks
  4. Commit to the Sprint
      

Mini summary: Sprint Planning is where the team decides what to do in the Sprint.


Lesson 9: Capacity Planning – How Much Can You Do?

Definition: Capacity planning is considering team availability – holidays, meetings, etc. – to adjust how much work you can take on.

Why it is important: It ensures you don't overcommit.

Simple explanation: It's like knowing you have a doctor's appointment on Wednesday, so you plan less work that day.

Real-life example: A team has a holiday on Friday – they reduce their capacity by 20%.

School example: A student has a sports practice on Tuesday – they study less that day.

Home example: A family has a relative visiting – they do fewer chores.

Nigerian example: A Nigerian team adjusts capacity for public holidays.

Illustration:

  Capacity = Available time - (holidays, meetings, etc.)
      

Mini summary: Capacity planning adjusts your work based on team availability.


Lesson 10: Release Planning – The Big Picture

Definition: Release planning is planning the delivery of a product version – usually over several Sprints.

Why it is important: It gives stakeholders a timeline for when features will be ready.

Simple explanation: It's like planning a road trip – you know where you'll stop each day.

Real-life example: A team plans to release a new version in 6 Sprints.

School example: A student plans to finish a project in 4 weeks.

Home example: A family plans a home renovation over 3 months.

Nigerian example: A Nigerian startup plans a product release in Q3.

Illustration:

  Release Plan:
  Sprint 1: Features A, B
  Sprint 2: Features C, D
  Sprint 3: Features E, F
  β†’ Release after Sprint 3
      

Mini summary: Release planning maps out when a product version will be delivered.


Lesson 11: The Cone of Uncertainty – Estimating Gets Better Over Time

Definition: The Cone of Uncertainty is a concept showing that estimates are very uncertain at the start of a project but become more accurate as you learn more.

Why it is important: It helps you understand that early estimates are rough and will improve.

Simple explanation: It's like predicting the weather – a week out is rough, but tomorrow is more accurate.

Real-life example: Early in a project, estimates might be off by 50%. Later, they might be off by only 10%.

School example: At the start of a term, your grade predictions are rough. As you get tests, they become more accurate.

Home example: Planning a party – early estimates of guests might be rough, but as you get RSVPs, they become more accurate.

Nigerian example: A Nigerian team knows that early estimates are not set in stone.

Illustration:

  Cone of Uncertainty:
  Start: Β±50% uncertainty
  Middle: Β±25%
  End: Β±10%
      

Mini summary: Estimates become more accurate as you learn more about the project.


Lesson 12: Planning Poker – Estimating Together

Definition: Planning Poker is a game where the team estimates stories together using cards with story point values.

Why it is important: It encourages discussion and leads to more accurate estimates.

Simple explanation: It's like a game where everyone shares their guess, then discusses why they chose it.

Real-life example: The team shows cards – some say 3, some say 5 – they discuss and agree on 3.

School example: A study group estimates how long a topic will take to learn – they discuss and agree.

Home example: A family estimates how long a task will take – they discuss and agree.

Nigerian example: A Nigerian team uses online planning poker for remote estimation.

Illustration:

  Planning Poker Cards:
  [1] [2] [3] [5] [8] [13] [20]
      

Mini summary: Planning Poker is a fun, collaborative way to estimate.


Lesson 13: The Sprint Goal – The Why

Definition: The Sprint Goal is a short statement that describes what the team plans to achieve in the Sprint.

Why it is important: It gives the Sprint a purpose and helps the team stay focused.

Simple explanation: It's like a mission for the Sprint – a clear goal to work towards.

Real-life example: "Build a working login feature."

School example: "Complete the history chapter."

Home example: "Clean the entire house."

Nigerian example: A Nigerian team's Sprint Goal: "Enable mobile payments."

Illustration:

  Sprint Goal: Clear, focused, achievable
      

Mini summary: The Sprint Goal is the purpose of the Sprint.


Lesson 14: Handling Changes – Adapting Your Plan

Definition: Plans can change – new information, customer feedback, or market shifts. Agile teams adapt.

Why it is important: Adapting keeps you on track to deliver value.

Simple explanation: It's like driving – if there's a roadblock, you find a new route.

Real-life example: A customer asks for a new feature – the team adjusts the backlog.

School example: A teacher adds a new assignment – the student adjusts their plan.

Home example: A guest arrives – the family adjusts their dinner plan.

Nigerian example: A Nigerian team reprioritises after a customer interview.

Illustration:

  Adapting = Responding to change
      

Mini summary: Be ready to adapt your plans when things change.


Lesson 15: Putting It All Together – The Planning Process

Definition: The full Agile planning process involves estimating stories, calculating velocity, and planning Sprints and releases.

Why it is important: It gives the team a clear roadmap.

Simple explanation: It's like planning a journey – you know your speed, your stops, and your destination.

Real-life example: A team estimates stories, calculates velocity, plans the Sprint, and creates a release plan.

School example: A student estimates study time, plans weekly goals, and sets exam targets.

Home example: A family estimates chores, plans weekly tasks, and sets monthly goals.

Nigerian example: A Nigerian team uses the full process to deliver products.

Illustration:

  Planning Process:
  1. Estimate stories (points)
  2. Calculate velocity
  3. Plan Sprint
  4. Plan release
  5. Adapt as needed
      

Mini summary: The planning process combines estimation, velocity, and planning for success.


Key Vocabulary (simple definitions)

  • Estimation: Predicting the effort of a task.
  • Story Points: A relative measure of effort.
  • Fibonacci Scale: 1,2,3,5,8,13 – used for points.
  • Velocity: Average points per Sprint.
  • Sprint Planning: Meeting to plan the Sprint.
  • Capacity: Available team time.
  • Release Planning: Planning a product release.
  • Cone of Uncertainty: Estimates become more accurate over time.
  • Planning Poker: Game for estimating together.
  • Sprint Goal: The purpose of the Sprint.

Important Concepts

  • Estimate effort, not time: Story points are about effort, not hours.
  • Use velocity for planning: Velocity helps you predict what you can do.
  • Plan together: Sprint Planning and Planning Poker are team activities.
  • Be ready to adapt: Plans change – be flexible.

Step-by-Step Explanations

How to Estimate a Story

  1. Read the user story and acceptance criteria.
  2. Think about the effort – not hours, but relative size.
  3. Use the Fibonacci scale (1,2,3,5,8,13).
  4. If using Planning Poker, everyone shows a card.
  5. Discuss differences and agree on a number.

How to Plan a Sprint

  1. Know your velocity (e.g., 20 points per Sprint).
  2. Select stories from the backlog that total your velocity.
  3. Break stories into tasks.
  4. Set a Sprint Goal.
  5. Commit to the Sprint.

Teacher Notes

  • Use the market day story to explain story points and velocity.
  • Have students practice estimating stories in class.
  • Teach Planning Poker as a fun game.
  • Discuss why estimates are not commitments – they are predictions.

Parent Tips

  • Help your child practice estimating tasks using story points.
  • Teach them to plan their week using a simple version of Sprint Planning.
  • Discuss how plans can change – and that's okay.

Interesting Facts & Did You Know?

  • Did you know? The Fibonacci sequence was invented by an Italian mathematician in the 13th century.
  • Interesting: Many teams use "T-shirt sizes" (XS, S, M, L, XL) instead of points – it's the same idea.
  • Did you know? Velocity is a team metric – it's not used to compare teams.
  • Nigeria: Nigerian teams are adopting Agile estimation to improve planning.

Remember This

  • Estimation predicts effort – not time.
  • Story points are relative and stable.
  • Velocity is your team's average points per Sprint.
  • Sprint Planning sets the direction for the Sprint.
  • Plans can change – be flexible.

Common Mistakes

  • Estimating in hours: Use story points, not hours.
  • Comparing velocity across teams: Velocity is team-specific – don't compare.
  • Overcommitting: Don't take on more than your velocity.
  • Not adjusting for capacity: Holidays and meetings affect your capacity.

Best Practices

  • Use the Fibonacci scale for points.
  • Estimate together using Planning Poker.
  • Calculate velocity over several Sprints.
  • Plan Sprints based on velocity and capacity.
  • Be ready to adapt your plans.

Illustrations & Diagrams

Story Point Scale

  β”Œβ”€β”€β”€β”€β”€β”€β”€β”¬β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”
  β”‚ Pointsβ”‚  Meaning                   β”‚
  β”œβ”€β”€β”€β”€β”€β”€β”€β”Όβ”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€
  β”‚ 1     β”‚  Very small (minutes)      β”‚
  β”‚ 2     β”‚  Small (hours)             β”‚
  β”‚ 3     β”‚  Medium (half day)         β”‚
  β”‚ 5     β”‚  Large (1-2 days)          β”‚
  β”‚ 8     β”‚  Very large (3-5 days)     β”‚
  β”‚ 13    β”‚  Too big – need to break   β”‚
  β””β”€β”€β”€β”€β”€β”€β”€β”΄β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”˜
      

Velocity Calculation

  Sprint 1: 20 points
  Sprint 2: 22 points
  Sprint 3: 18 points
  Velocity = (20 + 22 + 18) / 3 = 20 points
      

Comparison Tables

Story Points vs Hours

Story PointsHours
Relative effortAbsolute time
Stable across peopleVaries by person
Used for planningUsed for daily scheduling

Estimation Techniques

TechniqueDescription
Planning PokerGame with cards
Affinity MappingGrouping stories by size
T-Shirt SizesXS, S, M, L, XL

End-of-Module Summary

Great job! You have learned how to estimate and plan in Agile. You now know what story points are, why they are better than hours, and how to use the Fibonacci scale. You also learned about velocity, Sprint Planning, and release planning. Remember, estimates are predictions – not promises. They help you plan, but you must be ready to adapt. In Module 7, we will learn about Agile Metrics and Reporting – how to measure your team's performance and communicate progress. Keep planning!

Frequently Asked Questions (10)

  1. What is estimation? Predicting the effort of a task.
  2. What are story points? A relative measure of effort.
  3. What is the Fibonacci scale? 1,2,3,5,8,13.
  4. What is velocity? Average points per Sprint.
  5. What is Sprint Planning? A meeting to plan the Sprint.
  6. What is capacity? Available team time.
  7. What is release planning? Planning a product release.
  8. What is the Cone of Uncertainty? Estimates improve over time.
  9. What is Planning Poker? A game for estimation.
  10. What is a Sprint Goal? The purpose of the Sprint.

Review Questions (15)

  1. What is estimation?
  2. What are story points?
  3. Why use story points instead of hours?
  4. What is the Fibonacci sequence?
  5. What is velocity?
  6. How do you calculate velocity?
  7. What is Sprint Planning?
  8. What is capacity planning?
  9. What is release planning?
  10. What is the Cone of Uncertainty?
  11. What is Planning Poker?
  12. What is a Sprint Goal?
  13. What is the difference between estimation and planning?
  14. How does velocity help with planning?
  15. Why is it important to adapt plans?

Fill-in-the-Blank Exercises

  1. _______ is predicting the effort of a task. (Estimation)
  2. _______ points are a relative measure of effort. (Story)
  3. The Fibonacci sequence includes 1,2,3,5,8, and _______. (13)
  4. _______ is the average points per Sprint. (Velocity)
  5. _______ Planning is a meeting to plan the Sprint. (Sprint)
  6. The _______ of Uncertainty says estimates improve over time. (Cone)

True or False Exercises

  1. Story points are measured in hours. (False)
  2. Velocity is the average points per Sprint. (True)
  3. Planning Poker is a game for estimation. (True)
  4. The Cone of Uncertainty says estimates get worse over time. (False)
  5. Capacity planning considers team availability. (True)

Multiple Choice Questions (15)

  1. What are story points?
    A) A measure of time
    B) A relative measure of effort
    C) A type of story
    Answer: B
  2. What is velocity?
    A) The speed of a team
    B) Average points per Sprint
    C) A type of Sprint
    Answer: B
  3. What is the Fibonacci sequence?
    A) 1,2,3,5,8,13
    B) 1,2,4,8,16
    C) 1,3,5,7,9
    Answer: A
  4. What is Sprint Planning?
    A) A meeting to plan the Sprint
    B) A meeting to review the Sprint
    C) A meeting to estimate stories
    Answer: A
  5. What is capacity planning?
    A) Planning based on team availability
    B) Planning without considering holidays
    C) Planning the next year
    Answer: A
  6. What is release planning?
    A) Planning a product release
    B) Planning a Sprint
    C) Planning a meeting
    Answer: A
  7. What is the Cone of Uncertainty?
    A) Estimates get better over time
    B) Estimates get worse over time
    C) Estimates stay the same
    Answer: A
  8. What is Planning Poker?
    A) A game for estimation
    B) A game for fun
    C) A type of card game
    Answer: A
  9. What is a Sprint Goal?
    A) The purpose of the Sprint
    B) The list of tasks
    C) The end of the Sprint
    Answer: A
  10. Why use story points?
    A) They are stable
    B) They are in hours
    C) They are confusing
    Answer: A
  11. What is estimation?
    A) Predicting effort
    B) Predicting time
    C) Predicting cost
    Answer: A
  12. What is the difference between estimation and planning?
    A) Estimation predicts effort; planning decides what to do
    B) They are the same
    C) Planning predicts effort
    Answer: A
  13. How do you calculate velocity?
    A) Average points per Sprint
    B) Sum of all points
    C) Number of stories
    Answer: A
  14. Why should you adapt plans?
    A) Things change
    B) Plans are never wrong
    C) You shouldn't adapt
    Answer: A
  15. What is the benefit of Planning Poker?
    A) Encourages discussion
    B) Takes less time
    C) It's a fun game
    Answer: A

Matching Exercises

TermMeaning
1. Story PointsA. Relative measure of effort
2. VelocityB. Average points per Sprint
3. Sprint PlanningC. Meeting to plan the Sprint
4. Cone of UncertaintyD. Estimates improve over time
5. Planning PokerE. Game for estimation

Answers: 1-A, 2-B, 3-C, 4-D, 5-E

Short Answer Questions

  1. What is the difference between estimation and planning?
  2. What are story points and why are they useful?
  3. What is velocity and how do you calculate it?
  4. What is the Cone of Uncertainty?

Scenario-based Exercises

  • Scenario 1: Your team has a velocity of 20 points. Your backlog has stories of 3,5,8,2,3,5,8. How do you plan your Sprint?
  • Scenario 2: A new story comes in that is very large (13 points). What should you do?
  • Scenario 3: Your velocity is 20, but a team member is on holiday for 2 days. How do you adjust your capacity?

Group Activity

In groups, take a list of 5 stories. Estimate them using Planning Poker. Then plan a Sprint assuming a velocity of 10 points.

Individual Activity

Estimate 5 tasks you need to do this week using story points. Then plan your week based on your "velocity."

Classroom Discussion Questions

  • Why do you think story points are better than hours?
  • What would happen if you ignored velocity?
  • How do you feel when plans change?

Mini Project

Create a "Guide to Agile Estimation" poster for your classroom. Include story points, velocity, and Planning Poker.

Practical Assignment

Track your team's velocity over 3 Sprints (simulated or real). Write a short report on what you learned.

Challenge Exercise

Research how a Nigerian company uses Agile estimation. Write a summary and share with the class.

Quiz Answers

Multiple Choice answers: 1-B, 2-B, 3-A, 4-A, 5-A, 6-A, 7-A, 8-A, 9-A, 10-A, 11-A, 12-A, 13-A, 14-A, 15-A.

True/False answers: 1-F, 2-T, 3-T, 4-F, 5-T.

Key Takeaways

  • Estimation predicts effort – not time.
  • Story points are relative and stable.
  • Velocity is your team's average points per Sprint.
  • Sprint Planning sets the direction for the Sprint.
  • Plans can change – be flexible.

Preparation for the Next Module

In Module 7, we will learn about Agile Metrics and Reporting – how to measure your team's performance and communicate progress. You'll learn about burndown charts, cycle time, and how to keep stakeholders informed. Get ready to become a data-driven Agile developer!

8

Module Seven

Module 7: Agile Metrics and Reporting

Module Seven: Agile Metrics and Reporting – Measuring Your Success

Module Introduction

Hello, data detective! πŸ“Š In the last six modules, you learned about Agile frameworks, user stories, estimation, and planning. Now we are going to learn how to measure your team's performance using Agile metrics. Metrics are like numbers that tell you how well you are doing – like a score in a game. They help you see what is working and what needs improvement. By the end of this module, you'll know about burndown charts, velocity, cycle time, and how to report progress to your team and stakeholders. Let's get measuring!

Learning Objectives

By the end of this module, you will be able to:

  • Understand what Agile metrics are and why they matter.
  • Read and create a burndown chart.
  • Read and create a burnup chart.
  • Measure cycle time and throughput.
  • Use metrics to improve your team's performance.

Warm-up Story: The Scoreboard for the Football Team

In a small village in Nigeria, there was a football team called the "Agile Eagles." They played well, but they never knew how well they were doing. One day, the coach put up a big scoreboard that showed: goals scored, goals conceded, possession, and passes completed. The players could see their performance instantly. They noticed that when they made more passes, they scored more goals. They improved their passing, and their results got better. In Agile, we use metrics like burndown charts and velocity as our "scoreboard" – they help us see how we are doing and improve.

Main Lessons

Lesson 1: What Are Agile Metrics?

Definition: Agile metrics are numbers that measure how your team is performing – like how fast you deliver, how much work is done, and how long tasks take.

Why it is important: They help you understand your team's health and make improvements.

Simple explanation: It's like a fitness tracker for your team – it shows you how you are doing.

Real-life example: A team tracks their velocity to plan Sprints.

School example: A student tracks their grades to see improvement.

Home example: A family tracks how many chores they complete.

Nigerian example: A Nigerian team uses metrics to improve their delivery.

Illustration:

  Metrics = Numbers that show how your team is doing
      

Mini summary: Metrics help you understand and improve your team's performance.


Lesson 2: Why Metrics Matter

Definition: Metrics matter because they give you objective data to make decisions – not just feelings.

Why it is important: They help you see problems early and celebrate successes.

Simple explanation: It's like checking your temperature – you know if you are healthy or sick.

Real-life example: A team sees their cycle time increasing – they investigate and fix the bottleneck.

School example: A student sees their grades dropping – they study harder.

Home example: A family sees chores piling up – they redistribute tasks.

Nigerian example: A Nigerian team uses metrics to improve their process.

Illustration:

  Metrics β†’ Insights β†’ Improvements
      

Mini summary: Metrics give you data to make better decisions.


Lesson 3: Velocity – Your Team's Speed

Definition: Velocity is the average number of story points a team completes per Sprint. We learned this in Module 6 – it's a key metric.

Why it is important: It helps you plan future Sprints and measure productivity.

Simple explanation: It's like your car's speedometer – it shows how fast you're going.

Real-life example: A team's velocity is 20 points per Sprint.

School example: A student completes 5 assignments per week.

Home example: A family completes 10 chores per week.

Nigerian example: A Nigerian team tracks velocity to plan releases.

Illustration:

  Velocity = Average points per Sprint
      

Mini summary: Velocity measures how fast your team delivers.


Lesson 4: Burndown Chart – Tracking Work Remaining

Definition: A burndown chart shows how much work is left in a Sprint, day by day. It goes down as work is completed.

Why it is important: It helps you see if you are on track to finish the Sprint on time.

Simple explanation: It's like a countdown – you see how many tasks are left each day.

Real-life example: A team starts with 20 points of work. Each day, they burn down (finish) some points.

School example: A student has 10 chapters to study – each day they study one chapter.

Home example: A family has 5 rooms to clean – they clean one each day.

Nigerian example: A Nigerian team uses a burndown chart to track Sprint progress.

Illustration:

  Burndown Chart (simplified):
  Points
    ↑
  20 |  ●
  15 |  ●
  10 |  ●
   5 |  ●
   0 └────────────────→ Day
      Mon Tue Wed Thu Fri
      

Mini summary: A burndown chart shows remaining work in a Sprint.


Lesson 5: Burnup Chart – Tracking Work Completed

Definition: A burnup chart shows how much work has been completed in a Sprint, day by day. It goes up as work is done.

Why it is important: It shows progress toward the Sprint goal.

Simple explanation: It's like a thermometer – you see how much you have filled.

Real-life example: A team starts with 0 points done and completes 5 points on day 1, 10 on day 2, etc.

School example: A student tracks how many chapters they have read.

Home example: A family tracks how many rooms are cleaned.

Nigerian example: A Nigerian team uses a burnup chart to show stakeholders progress.

Illustration:

  Burnup Chart (simplified):
  Points
    ↑
  20 |          ●
  15 |        ●
  10 |      ●
   5 |    ●
   0 |  ●
      └────────────────→ Day
      Mon Tue Wed Thu Fri
      

Mini summary: A burnup chart shows completed work in a Sprint.


Lesson 6: Cycle Time – How Long Does It Take?

Definition: Cycle time is the time it takes for a task to go from "started" to "done."

Why it is important: It tells you how fast you are delivering individual tasks.

Simple explanation: It's like measuring how long it takes to bake a cake – from start to finish.

Real-life example: A task takes 2 days from start to finish – cycle time = 2 days.

School example: It takes 3 days to write an essay – cycle time = 3 days.

Home example: It takes 1 hour to clean a room – cycle time = 1 hour.

Nigerian example: A Nigerian team tracks cycle time to improve flow.

Illustration:

  Cycle Time = Time from start to finish
      

Mini summary: Cycle time measures how long individual tasks take.


Lesson 7: Throughput – How Many Tasks Per Week?

Definition: Throughput is the number of tasks completed in a given time period (e.g., per week or per Sprint).

Why it is important: It shows how productive the team is.

Simple explanation: It's like counting how many cakes you bake in a week.

Real-life example: A team completes 10 tasks per week.

School example: A student completes 3 assignments per week.

Home example: A family completes 7 chores per week.

Nigerian example: A Nigerian team measures throughput to plan capacity.

Illustration:

  Throughput = Tasks completed per period
      

Mini summary: Throughput measures how many tasks you complete.


Lesson 8: Cumulative Flow Diagram – The Big Picture

Definition: A Cumulative Flow Diagram (CFD) shows the number of tasks in each stage of your workflow over time.

Why it is important: It helps you spot bottlenecks – where work is piling up.

Simple explanation: It's like a traffic map – you see where cars (tasks) are stuck.

Real-life example: The CFD shows that tasks are piling up in the "Testing" column – time to add more testers.

School example: A student sees that they are piling up assignments – they adjust their schedule.

Home example: A family sees that dishes are piling up – they decide to wash them more often.

Nigerian example: A Nigerian team uses a CFD to improve their workflow.

Illustration:

  Cumulative Flow Diagram (simplified):
  Tasks
    ↑
  10 β”‚  To Do
  8  β”‚  In Progress
  6  β”‚  Done
  4  β”‚
  2  β”‚
  0 └────────────────→ Time
      

Mini summary: A CFD shows the flow of tasks over time and helps spot bottlenecks.


Lesson 9: Lead Time – From Idea to Delivery

Definition: Lead time is the time it takes from a request being made to the task being completed.

Why it is important: It measures the total time the customer waits.

Simple explanation: It's like ordering a pizza – from the time you order to the time you get it.

Real-life example: A customer requests a feature; it takes 4 weeks to deliver – lead time = 4 weeks.

School example: A student asks for help; the teacher responds in 1 day – lead time = 1 day.

Home example: A parent asks a child to clean; it takes 2 hours – lead time = 2 hours.

Nigerian example: A Nigerian team tracks lead time to improve customer satisfaction.

Illustration:

  Lead Time = Time from request to delivery
      

Mini summary: Lead time measures how long customers wait.


Lesson 10: Sprint Review – Reporting to Stakeholders

Definition: The Sprint Review is a meeting where the team shows what they built and presents metrics to stakeholders.

Why it is important: It keeps stakeholders informed and builds trust.

Simple explanation: It's like a show-and-tell for your work.

Real-life example: The team shows a demo and shares velocity, burndown, and cycle time.

School example: A student presents their project to the class.

Home example: A family shares their weekly accomplishments.

Nigerian example: A Nigerian team presents metrics during Sprint Review.

Illustration:

  Sprint Review = Demo + Metrics + Feedback
      

Mini summary: Sprint Review is where you share your progress and metrics.


Lesson 11: Retrospective – Using Metrics to Improve

Definition: In the Sprint Retrospective, the team discusses metrics and identifies ways to improve.

Why it is important: It turns data into action.

Simple explanation: It's like a post-game review – you look at the numbers and decide what to do differently.

Real-life example: The team sees cycle time increasing and decides to pair program more.

School example: A student sees their grades dropping and decides to study differently.

Home example: A family sees chores piling up and decides to create a schedule.

Nigerian example: A Nigerian team uses metrics in their retrospective to improve.

Illustration:

  Retrospective = Review metrics + Plan improvements
      

Mini summary: The retrospective uses metrics to plan improvements.


Lesson 12: Common Metrics Mistakes

Definition: Mistakes include comparing velocity across teams, using metrics to punish people, or focusing on the wrong metrics.

Why it is important: Avoid these to keep your team healthy and motivated.

Simple explanation: It's like using the wrong tool for a job – it doesn't work.

Real-life example: A manager compares velocity between teams – this is a mistake.

School example: A teacher compares students' grades publicly – not helpful.

Home example: A parent compares children's chore completion – not fair.

Nigerian example: A Nigerian team avoids comparing velocity across teams.

Illustration:

  Mistakes:
  - Comparing velocity across teams
  - Using metrics as a weapon
  - Focusing on vanity metrics
      

Mini summary: Use metrics to improve, not to punish or compare.


Lesson 13: Using Metrics for Continuous Improvement

Definition: Metrics are most powerful when you use them to identify problems and make changes.

Why it is important: Continuous improvement is the heart of Agile – metrics fuel it.

Simple explanation: It's like using a map – you see where you are and where to go.

Real-life example: A team sees that testing is a bottleneck and adds more testers.

School example: A student sees they are weak in math and spends more time on it.

Home example: A family sees that laundry is piling up and does it more often.

Nigerian example: A Nigerian team uses metrics to continuously improve.

Illustration:

  Metrics β†’ Identify problems β†’ Make changes β†’ Measure again
      

Mini summary: Use metrics to drive continuous improvement.


Lesson 14: Visualising Metrics – Dashboards

Definition: A dashboard is a visual display of your key metrics – like a car's dashboard.

Why it is important: It gives you a quick, at-a-glance view of your team's health.

Simple explanation: It's like a scoreboard that shows all the important numbers.

Real-life example: A team has a dashboard showing velocity, burndown, and cycle time.

School example: A student has a dashboard showing grades, assignments, and study time.

Home example: A family has a dashboard showing chores completed.

Nigerian example: A Nigerian team uses Jira dashboards for metrics.

Illustration:

  Dashboard:
  β”Œβ”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”
  β”‚  Velocity: 20                 β”‚
  β”‚  Cycle Time: 2 days           β”‚
  β”‚  Throughput: 10 tasks/week    β”‚
  β””β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”˜
      

Mini summary: Dashboards visualise key metrics for easy monitoring.


Lesson 15: Putting It All Together – A Metrics Culture

Definition: A metrics culture is an environment where teams use data to make decisions and improve.

Why it is important: It builds trust, transparency, and a focus on delivery.

Simple explanation: It's like a team that uses a scoreboard to get better together.

Real-life example: A team reviews metrics in every Retrospective and celebrates improvements.

School example: A study group tracks their progress and cheers each other on.

Home example: A family tracks their chores and celebrates when they are all done.

Nigerian example: A Nigerian team builds a metrics culture for success.

Illustration:

  Metrics Culture = Data + Transparency + Improvement
      

Mini summary: A metrics culture helps teams improve together.


Key Vocabulary (simple definitions)

  • Metrics: Numbers that measure team performance.
  • Velocity: Average points per Sprint.
  • Burndown Chart: Shows remaining work in a Sprint.
  • Burnup Chart: Shows completed work in a Sprint.
  • Cycle Time: Time from start to finish for a task.
  • Throughput: Tasks completed per period.
  • Cumulative Flow Diagram: Shows task flow over time.
  • Lead Time: Time from request to delivery.
  • Sprint Review: Meeting to show progress.
  • Retrospective: Meeting to improve.

Important Concepts

  • Data-driven decisions: Use metrics to guide choices.
  • Transparency: Share metrics openly with the team.
  • Continuous improvement: Metrics fuel improvement.
  • No blame: Metrics are for learning, not punishing.

Step-by-Step Explanations

How to Create a Burndown Chart

  1. List the total points in the Sprint (e.g., 20).
  2. Plot the ideal burndown line: from 20 points on day 1 to 0 on the last day.
  3. Each day, update the remaining points.
  4. Plot the actual line based on your updates.
  5. Compare actual vs. ideal to see if you are on track.

How to Calculate Cycle Time

  1. Note the date and time when a task moves to "In Progress".
  2. Note the date and time when it moves to "Done".
  3. Calculate the difference – that is the cycle time.
  4. Average the cycle times of several tasks.

Teacher Notes

  • Use the scoreboard story to make metrics relatable.
  • Have students draw a burndown chart on paper.
  • Discuss how metrics can be misused – and how to avoid that.
  • Emphasise that metrics are for improvement, not judgment.

Parent Tips

  • Help your child track their progress on a simple burndown chart.
  • Use metrics to celebrate improvement, not just finish.
  • Teach them that numbers help us get better.

Interesting Facts & Did You Know?

  • Did you know? The first burndown chart was created by Ken Schwaber, one of the founders of Scrum.
  • Interesting: Many teams use dashboards with real-time metrics to stay aligned.
  • Did you know? Cycle time is a key metric in Lean manufacturing.
  • Nigeria: Nigerian teams are increasingly using data dashboards to track progress.

Remember This

  • Metrics help you understand your team's performance.
  • Velocity, burndown, burnup, cycle time, and throughput are key metrics.
  • Use metrics to improve, not to punish.
  • Share metrics openly with the team.
  • Celebrate improvements and learning.

Common Mistakes

  • Comparing velocity across teams: Each team is different.
  • Using metrics as a weapon: Metrics should help, not hurt.
  • Focusing on vanity metrics: Only track what matters.
  • Ignoring metrics: Don't collect data if you won't use it.

Best Practices

  • Track a few key metrics (not too many).
  • Use metrics to drive improvements.
  • Share metrics with the whole team.
  • Celebrate improvements and learning.
  • Use dashboards for visibility.

Illustrations & Diagrams

Burndown Chart Example

  Points
    ↑
  20 β”‚  ●
  15 β”‚     ●
  10 β”‚        ●
   5 β”‚           ●
   0 β”‚              ●
      └───────────────→ Day
      Mon  Tue  Wed  Thu  Fri
      

Cycle Time and Throughput

  Cycle Time = 2 days
  Throughput = 5 tasks/week
      

Comparison Tables

Burndown vs Burnup Chart

BurndownBurnup
Shows work remainingShows work completed
Goes downGoes up
Helps track Sprint progressHelps show progress toward goal

Cycle Time vs Lead Time

Cycle TimeLead Time
From start to finishFrom request to delivery
Team-focusedCustomer-focused

End-of-Module Summary

Excellent work! You have learned how to measure your team's performance using Agile metrics. You now understand velocity, burndown charts, burnup charts, cycle time, throughput, and cumulative flow diagrams. You also know how to use these metrics to improve your team and report progress to stakeholders. Remember, metrics are tools for learning and growth – not weapons for comparison. In Module 8, we will learn about Scaling Agile – how to apply Agile practices to large teams and organisations. Keep measuring and improving!

Frequently Asked Questions (10)

  1. What are Agile metrics? Numbers that measure team performance.
  2. What is velocity? Average points per Sprint.
  3. What is a burndown chart? Shows remaining work in a Sprint.
  4. What is a burnup chart? Shows completed work in a Sprint.
  5. What is cycle time? Time from start to finish.
  6. What is throughput? Tasks completed per period.
  7. What is a Cumulative Flow Diagram? Shows task flow over time.
  8. What is lead time? Time from request to delivery.
  9. Why are metrics important? They help you improve.
  10. What is a metrics culture? Using data to make decisions.

Review Questions (15)

  1. What are Agile metrics?
  2. What is velocity?
  3. What is a burndown chart?
  4. What is a burnup chart?
  5. What is cycle time?
  6. What is throughput?
  7. What is a Cumulative Flow Diagram?
  8. What is lead time?
  9. How does velocity help with planning?
  10. What is the difference between cycle time and lead time?
  11. Why should you not compare velocity across teams?
  12. How can you use metrics to improve?
  13. What is the Sprint Review?
  14. What is the Retrospective?
  15. What is a metrics culture?

Fill-in-the-Blank Exercises

  1. _______ is the average points per Sprint. (Velocity)
  2. A _______ chart shows remaining work in a Sprint. (burndown)
  3. A _______ chart shows completed work in a Sprint. (burnup)
  4. _______ time is from start to finish. (Cycle)
  5. _______ is the number of tasks completed per period. (Throughput)
  6. _______ time is from request to delivery. (Lead)

True or False Exercises

  1. Velocity is the same for all teams. (False)
  2. A burndown chart goes down. (True)
  3. A burnup chart goes up. (True)
  4. Cycle time is measured from request to delivery. (False)
  5. Metrics should be used to punish people. (False)

Multiple Choice Questions (15)

  1. What is velocity?
    A) Average points per Sprint
    B) Time from start to finish
    C) Tasks per week
    Answer: A
  2. What does a burndown chart show?
    A) Remaining work
    B) Completed work
    C) Cycle time
    Answer: A
  3. What does a burnup chart show?
    A) Remaining work
    B) Completed work
    C) Velocity
    Answer: B
  4. What is cycle time?
    A) Time from start to finish
    B) Time from request to delivery
    C) Tasks per week
    Answer: A
  5. What is throughput?
    A) Tasks per period
    B) Time from start to finish
    C) Average points per Sprint
    Answer: A
  6. What is lead time?
    A) Time from request to delivery
    B) Time from start to finish
    C) Tasks per week
    Answer: A
  7. What is a Cumulative Flow Diagram?
    A) Shows task flow over time
    B) Shows remaining work
    C) Shows completed work
    Answer: A
  8. Why should you not compare velocity across teams?
    A) Teams are different
    B) It's easy
    C) It's fun
    Answer: A
  9. What is the Sprint Review?
    A) Meeting to show progress
    B) Meeting to improve
    C) Meeting to estimate
    Answer: A
  10. What is the Retrospective?
    A) Meeting to improve
    B) Meeting to show progress
    C) Meeting to plan
    Answer: A
  11. What is a metrics culture?
    A) Using data to improve
    B) Ignoring metrics
    C) Comparing teams
    Answer: A
  12. How can metrics help?
    A) Identify problems
    B) Punish people
    C) Compare teams
    Answer: A
  13. What is a common mistake?
    A) Using metrics as a weapon
    B) Using metrics to improve
    C) Sharing metrics
    Answer: A
  14. What is a dashboard?
    A) Visual display of metrics
    B) A type of chart
    C) A meeting
    Answer: A
  15. What is the goal of metrics?
    A) Continuous improvement
    B) Punishment
    C) Competition
    Answer: A

Matching Exercises

TermMeaning
1. VelocityA. Average points per Sprint
2. BurndownB. Shows remaining work
3. BurnupC. Shows completed work
4. Cycle TimeD. Time from start to finish
5. ThroughputE. Tasks per period

Answers: 1-A, 2-B, 3-C, 4-D, 5-E

Short Answer Questions

  1. What is the difference between a burndown and a burnup chart?
  2. What is cycle time and why is it useful?
  3. What is the difference between cycle time and lead time?
  4. Why should you not compare velocity across teams?

Scenario-based Exercises

  • Scenario 1: Your burndown chart shows that work is not burning down as fast as expected. What do you do?
  • Scenario 2: Your cycle time is increasing. What could be the cause?
  • Scenario 3: A stakeholder asks you how the project is going. What metrics would you show them?

Group Activity

In groups, create a burndown chart for a 5-day Sprint with 20 points. Assume you complete 4 points each day. Draw the ideal line and the actual line.

Individual Activity

Track your own tasks for one week. Measure your cycle time and throughput. Write a short report on what you learned.

Classroom Discussion Questions

  • What would happen if you didn't track metrics?
  • How do you feel when you see your metrics improving?
  • What is the most important metric for a team?

Mini Project

Create a one-page "Metrics Dashboard" for a fictional team. Include velocity, burndown, cycle time, and throughput.

Practical Assignment

If you have a project, track your team's velocity and cycle time for 2 Sprints. Write a report on what you learned.

Challenge Exercise

Research how a Nigerian company uses Agile metrics. Write a summary and share with the class.

Quiz Answers

Multiple Choice answers: 1-A, 2-A, 3-B, 4-A, 5-A, 6-A, 7-A, 8-A, 9-A, 10-A, 11-A, 12-A, 13-A, 14-A, 15-A.

True/False answers: 1-F, 2-T, 3-T, 4-F, 5-F.

Key Takeaways

  • Agile metrics measure team performance.
  • Velocity, burndown, burnup, cycle time, and throughput are key.
  • Use metrics to improve, not to punish.
  • Share metrics openly with the team.
  • Celebrate improvements and learning.

Preparation for the Next Module

In Module 8, we will learn about Scaling Agile – how to apply Agile practices to large teams and organisations. You'll learn about frameworks like SAFe, LeSS, and how to coordinate multiple teams. Get ready to scale up!

9

Module Eight

Module 8: Scaling Agile – Going Big

Module Eight: Scaling Agile – Going Big

Module Introduction

Hello, big thinker! 🌍 In the last seven modules, you learned how to be Agile in a single team. But what happens when your company grows and you have many teams? How do you keep everyone working together? That's called scaling Agile. It's like a football team expanding to a whole league – you need new ways to coordinate. In this module, we will learn about frameworks like SAFe, LeSS, and how to make Agile work for large organisations. By the end, you'll understand how to apply Agile at any scale. Let's go big!

Learning Objectives

By the end of this module, you will be able to:

  • Explain why scaling Agile is needed.
  • Describe the SAFe framework.
  • Describe the LeSS framework.
  • Understand the challenges of scaling Agile.
  • Identify key practices for scaling successfully.

Warm-up Story: The Market in the Big City

In a small village, there was one market stall that was very popular. The owner, Mama Nkechi, knew all her customers by name. She was fast and friendly. But one day, the village grew into a big city. More stalls opened – over 100 of them! Mama Nkechi couldn't do everything herself. She needed a system to manage all the stalls, keep them coordinated, and ensure everyone got what they needed. She created a "market council" with leaders from each section. They met weekly, shared information, and made plans together. The market thrived. That's what scaling Agile is – taking what works for one team and making it work for many teams.

Main Lessons

Lesson 1: Why Scale Agile?

Definition: Scaling Agile means applying Agile principles to large organisations with many teams working on the same product.

Why it is important: As companies grow, they need to keep the agility of small teams while coordinating across many teams.

Simple explanation: It's like teaching many people to play in an orchestra – they each play their part, but they need a conductor.

Real-life example: A large bank with 20 development teams wants to use Agile across all of them.

School example: A school with many classes wants all teachers to use the same teaching method.

Home example: A large family wants everyone to follow the same cleaning schedule.

Nigerian example: A Nigerian telecom company wants to scale Agile across its software teams.

Illustration:

  One Team β†’ Many Teams β†’ Need to coordinate
      

Mini summary: Scaling Agile helps large organisations stay agile.


Lesson 2: The Challenges of Scaling

Definition: Challenges include communication, coordination, shared goals, and keeping the Agile spirit alive.

Why it is important: Without solving these, scaling can lead to confusion and delays.

Simple explanation: It's like having many cooks in a kitchen – they need to work together or the meal will be a mess.

Real-life example: Different teams build different parts of the same product – they need to integrate.

School example: Different teachers need to coordinate their lesson plans.

Home example: Family members need to coordinate their schedules.

Nigerian example: A Nigerian company with multiple offices needs to coordinate projects.

Illustration:

  Challenges:
  - Communication
  - Coordination
  - Shared vision
  - Keeping Agile culture
      

Mini summary: Scaling brings challenges like communication and coordination.


Lesson 3: SAFe – The Scaled Agile Framework

Definition: SAFe (Scaled Agile Framework) is a popular framework for scaling Agile. It adds layers like Program, Portfolio, and Solution to coordinate multiple teams.

Why it is important: It gives a clear structure for large organisations to adopt Agile.

Simple explanation: It's like having a company structure – teams, departments, and divisions.

Real-life example: A large enterprise uses SAFe to manage hundreds of teams.

School example: A school district uses SAFe-like coordination across schools.

Home example: A large family uses a structure with a parent coordinating different areas.

Nigerian example: A Nigerian bank uses SAFe to coordinate its development teams.

Illustration:

  SAFe Levels:
  Team β†’ Program β†’ Large Solution β†’ Portfolio
      

Mini summary: SAFe is a framework for scaling Agile with multiple levels.


Lesson 4: LeSS – Large-Scale Scrum

Definition: LeSS (Large-Scale Scrum) is a scaling framework that extends Scrum to many teams working on one product.

Why it is important: It keeps the simplicity of Scrum while adding coordination between teams.

Simple explanation: It's like having multiple Scrum teams working on the same product – they share a single Product Backlog.

Real-life example: 10 Scrum teams work on one product, using one Product Backlog.

School example: Several classes share the same curriculum and exams.

Home example: Family members share a common to-do list.

Nigerian example: A Nigerian product company uses LeSS to coordinate multiple Scrum teams.

Illustration:

  LeSS: One Product Backlog, Many Scrum Teams
      

Mini summary: LeSS extends Scrum to multiple teams with one Product Backlog.


Lesson 5: LeSS vs SAFe – Comparison

Definition: LeSS is simpler and keeps Scrum intact. SAFe is more comprehensive and adds many roles and practices.

Why it is important: You need to choose the right framework for your organisation.

Simple explanation: LeSS is like a small backpack – light and simple. SAFe is like a large suitcase – more organised but heavier.

Real-life example: A company with 5 teams might use LeSS; a company with 50 teams might use SAFe.

School example: A school with a few classes might use LeSS; a large school district might use SAFe.

Home example: A small family might use LeSS; a large extended family might use SAFe.

Nigerian example: A Nigerian startup might use LeSS; a large corporation might use SAFe.

Illustration:

  LeSS: Simple, minimal
  SAFe: Comprehensive, structured
      

Mini summary: LeSS is simpler; SAFe is more comprehensive.


Lesson 6: The Agile Release Train (ART) – SAFe's Engine

Definition: In SAFe, an Agile Release Train (ART) is a group of teams that work together to deliver value in a Program Increment (PI).

Why it is important: It coordinates multiple teams to deliver a large solution.

Simple explanation: It's like a train with many carriages – all moving together toward the same destination.

Real-life example: 5 teams work together on a new banking system – they are an ART.

School example: 3 classes work together on a school-wide project – they form an ART.

Home example: Family members work together on a home renovation.

Nigerian example: A Nigerian company forms an ART to build a new mobile app.

Illustration:

  ART = Agile Release Train (Teams working together)
      

Mini summary: An ART is a group of teams delivering value together.


Lesson 7: Program Increment (PI) – SAFe's Big Sprint

Definition: A Program Increment (PI) is a time-box of 8-12 weeks where an ART delivers value.

Why it is important: It provides a bigger planning horizon for multiple teams.

Simple explanation: It's like a super Sprint – many Sprints combined into one big cycle.

Real-life example: An ART plans a PI with 4 Sprints of 2 weeks each.

School example: A school has a 3-month term with weekly planning.

Home example: A family has a 3-month plan for a big project.

Nigerian example: A Nigerian company uses PIs to plan their releases.

Illustration:

  PI = Program Increment (8-12 weeks)
      

Mini summary: A PI is a long-term planning cycle for multiple teams.


Lesson 8: PI Planning – The Big Planning Event

Definition: PI Planning is a 2-day event where all teams in an ART plan the next PI together.

Why it is important: It aligns all teams on a shared vision and plan.

Simple explanation: It's like a big meeting where everyone plans the next few months.

Real-life example: Teams gather to plan the next PI – they create a plan and commit to it.

School example: Teachers gather to plan the next term's curriculum.

Home example: Family members gather to plan a big holiday.

Nigerian example: A Nigerian company holds PI Planning for all teams.

Illustration:

  PI Planning: 2-day event, all teams together
      

Mini summary: PI Planning aligns all teams on a shared plan.


Lesson 9: Scrum of Scrums – Coordinating Teams

Definition: Scrum of Scrums is a meeting where representatives from each team coordinate and share progress.

Why it is important: It keeps teams aligned and resolves cross-team issues.

Simple explanation: It's like a meeting of team captains to coordinate the game.

Real-life example: Each team sends a member to a daily Scrum of Scrums.

School example: Class representatives meet to coordinate school activities.

Home example: Family members meet to coordinate weekly tasks.

Nigerian example: A Nigerian company uses Scrum of Scrums to coordinate teams.

Illustration:

  Scrum of Scrums = Team reps meet to coordinate
      

Mini summary: Scrum of Scrums coordinates multiple teams.


Lesson 10: Shared Vision – All Teams Aim for the Same Goal

Definition: A shared vision is a common understanding of what the product is and where it's going.

Why it is important: Without a shared vision, teams pull in different directions.

Simple explanation: It's like everyone on a ship rowing in the same direction.

Real-life example: All teams understand that they are building a customer-facing banking app.

School example: All teachers understand the school's mission.

Home example: All family members agree on a holiday destination.

Nigerian example: A Nigerian company has a clear product vision shared by all teams.

Illustration:

  Shared Vision = Everyone knows where we're going
      

Mini summary: A shared vision aligns all teams toward the same goal.


Lesson 11: Integration and Testing at Scale

Definition: Integration means combining work from different teams. At scale, it's more complex and must be done often.

Why it is important: Without frequent integration, many problems arise.

Simple explanation: It's like building a puzzle – pieces must fit together.

Real-life example: Teams use a shared CI/CD pipeline to integrate daily.

School example: Teachers share lesson plans to ensure consistency.

Home example: Family members share a calendar to avoid conflicts.

Nigerian example: A Nigerian company has a central integration team.

Illustration:

  Integration = Putting pieces together
      

Mini summary: Frequent integration prevents problems in large projects.


Lesson 12: Continuous Improvement at Scale

Definition: Continuous improvement means always looking for ways to get better – this applies to the whole organisation.

Why it is important: Large organisations need a systematic way to improve.

Simple explanation: It's like the whole league getting better, not just one team.

Real-life example: The organisation holds a quarterly "Improvement Day."

School example: The school holds a yearly review to improve.

Home example: The family holds a monthly review to improve.

Nigerian example: A Nigerian company has a yearly improvement summit.

Illustration:

  Continuous Improvement = Always getting better together
      

Mini summary: Continuous improvement is essential for scaling Agile.


Lesson 13: Common Mistakes When Scaling

Definition: Mistakes include scaling too fast, losing the Agile culture, and focusing on tools over people.

Why it is important: Avoid these to keep your Agile transformation successful.

Simple explanation: It's like trying to run before you can walk – you'll fall.

Real-life example: A company forces SAFe on everyone without training – it fails.

School example: A school forces a new method on all teachers without support.

Home example: A family forces a new chore system without discussion.

Nigerian example: A Nigerian company scales too fast and loses its Agile culture.

Illustration:

  Mistakes:
  - Scaling too fast
  - Losing the culture
  - Overemphasis on tools
      

Mini summary: Scaling too fast or losing culture are common mistakes.


Lesson 14: Best Practices for Scaling

Definition: Best practices include starting small, maintaining Agile values, and focusing on communication.

Why it is important: They increase the chance of successful scaling.

Simple explanation: It's like building a skyscraper – you start with a solid foundation.

Real-life example: A company starts with one ART, learns, and then adds more.

School example: A school starts with one grade level, then expands.

Home example: A family starts with a small project, then bigger ones.

Nigerian example: A Nigerian company scales gradually, learning at each step.

Illustration:

  Best Practices:
  - Start small
  - Keep values alive
  - Foster communication
      

Mini summary: Start small and keep Agile values to scale successfully.


Lesson 15: The Future of Scaling Agile

Definition: The future includes more hybrid models, AI-assisted coordination, and continuous learning.

Why it is important: Scaling Agile is always evolving – stay informed.

Simple explanation: It's like the game of football – rules and strategies keep evolving.

Real-life example: Companies are using AI to help coordinate teams.

School example: Schools are using technology to coordinate across classes.

Home example: Families use apps to coordinate schedules.

Nigerian example: Nigerian companies are exploring new ways to scale Agile.

Illustration:

  Future: Hybrid models, AI, continuous learning
      

Mini summary: Scaling Agile continues to evolve with new technologies.


Key Vocabulary (simple definitions)

  • Scaling: Applying Agile to many teams.
  • SAFe: Scaled Agile Framework – a comprehensive scaling framework.
  • LeSS: Large-Scale Scrum – a simple scaling framework.
  • ART: Agile Release Train – a group of teams in SAFe.
  • PI: Program Increment – a long planning cycle.
  • PI Planning: A 2-day event to plan a PI.
  • Scrum of Scrums: Coordination meeting of team representatives.
  • Shared Vision: Common understanding of the product goal.
  • Integration: Combining work from different teams.
  • Continuous Improvement: Always finding ways to get better.

Important Concepts

  • Coordination: Many teams need to work together.
  • Alignment: Teams need a shared vision and plan.
  • Culture: Keeping the Agile culture is key.
  • Gradual scaling: Start small and learn.

Step-by-Step Explanations

How to Start Scaling Agile

  1. Start with one team – get them working well.
  2. Add a second team and coordinate them (e.g., Scrum of Scrums).
  3. Introduce a shared vision and backlog.
  4. Gradually add more teams.
  5. Consider a scaling framework like LeSS or SAFe when you have 5+ teams.

How to Run a PI Planning Event

  1. Gather all teams in one room (or virtual).
  2. Present the product vision and top priorities.
  3. Each team plans what they can deliver in the PI.
  4. Teams negotiate dependencies and adjust plans.
  5. Commit to a final plan.

Teacher Notes

  • Use the market story to explain scaling.
  • Compare LeSS and SAFe to help students understand differences.
  • Emphasise that scaling is about coordination, not complexity.
  • Encourage discussion about scaling challenges.

Parent Tips

  • Help your child understand coordination in large groups.
  • Discuss how schools or organisations coordinate many people.
  • Teach them that scaling takes time and patience.

Interesting Facts & Did You Know?

  • Did you know? SAFe was created by Dean Leffingwell in 2011.
  • Interesting: LeSS was created by Craig Larman and Bas Vodde.
  • Did you know? Many Fortune 500 companies use SAFe.
  • Nigeria: Nigerian companies are increasingly adopting scaling frameworks.

Remember This

  • Scaling Agile is about coordinating many teams.
  • SAFe and LeSS are popular scaling frameworks.
  • LeSS is simpler; SAFe is more comprehensive.
  • Start small and maintain Agile values.
  • Continuous improvement is key.

Common Mistakes

  • Scaling too fast: Teams aren't ready.
  • Losing the culture: Becoming bureaucratic.
  • Overemphasising tools: Tools don't replace culture.
  • Ignoring communication: Teams work in silos.

Best Practices

  • Start with one team and grow gradually.
  • Keep Agile values and principles alive.
  • Invest in communication and coordination.
  • Use a framework that fits your organisation.
  • Continuously improve your scaling approach.

Illustrations & Diagrams

SAFe Levels

  β”Œβ”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”
  β”‚  Portfolio Level (Strategy)                     β”‚
  β”‚    β”‚                                             β”‚
  β”‚  Solution Level (Large Products)                β”‚
  β”‚    β”‚                                             β”‚
  β”‚  Program Level (ART)                            β”‚
  β”‚    β”‚                                             β”‚
  β”‚  Team Level (Scrum/Kanban)                      β”‚
  β””β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”˜
      

LeSS Structure

  One Product Backlog
  β”Œβ”€β”€β”€β”€β”€β”€β”¬β”€β”€β”€β”€β”€β”€β”¬β”€β”€β”€β”€β”€β”€β”¬β”€β”€β”€β”€β”€β”€β”
  β”‚Team Aβ”‚Team Bβ”‚Team Cβ”‚Team Dβ”‚
  β””β”€β”€β”€β”€β”€β”€β”΄β”€β”€β”€β”€β”€β”€β”΄β”€β”€β”€β”€β”€β”€β”΄β”€β”€β”€β”€β”€β”€β”˜
      

Comparison Tables

LeSS vs SAFe

LeSSSAFe
Simple, minimalComprehensive, structured
Extends ScrumAdds many new roles
One Product BacklogMultiple backlogs
Fewer rolesMany roles
Easier to adoptHarder to adopt

Scaling Frameworks Overview

FrameworkBest For
Scrum of Scrums2-5 teams
LeSSUp to 8 teams
SAFe10+ teams
Nexus3-9 teams

End-of-Module Summary

Excellent work! You have learned how to scale Agile from one team to many. You now understand the challenges of scaling, the SAFe framework, the LeSS framework, and key practices like PI Planning and Scrum of Scrums. Remember, scaling is about coordination, not complication. Start small, keep the Agile culture, and continuously improve. In Module 9, we will explore Agile Leadership and Culture – how to lead Agile teams and build a great culture. Keep scaling!

Frequently Asked Questions (10)

  1. What is scaling Agile? Applying Agile to many teams.
  2. What is SAFe? A comprehensive scaling framework.
  3. What is LeSS? A simple scaling framework.
  4. What is an ART? A group of teams in SAFe.
  5. What is a PI? A long planning cycle.
  6. What is PI Planning? A 2-day event to plan.
  7. What is Scrum of Scrums? Coordination meeting.
  8. What is a shared vision? Common product goal.
  9. What is a common mistake? Scaling too fast.
  10. What is a best practice? Starting small.

Review Questions (15)

  1. Why do we need to scale Agile?
  2. What are the challenges of scaling?
  3. What is SAFe?
  4. What is LeSS?
  5. How do LeSS and SAFe differ?
  6. What is an ART?
  7. What is a PI?
  8. What is PI Planning?
  9. What is Scrum of Scrums?
  10. What is a shared vision?
  11. What is integration at scale?
  12. Why is continuous improvement important?
  13. What is a common mistake when scaling?
  14. What is a best practice for scaling?
  15. What is the future of scaling Agile?

Fill-in-the-Blank Exercises

  1. _______ is applying Agile to many teams. (Scaling)
  2. _______ is a comprehensive scaling framework. (SAFe)
  3. _______ is a simple scaling framework. (LeSS)
  4. An _______ is a group of teams in SAFe. (ART)
  5. _______ is a long planning cycle in SAFe. (PI)
  6. _______ of Scrums coordinates multiple teams. (Scrum)

True or False Exercises

  1. Scaling Agile is only for software teams. (False)
  2. LeSS is more complex than SAFe. (False)
  3. SAFe has a level called Portfolio. (True)
  4. Scrum of Scrums is a meeting for coordination. (True)
  5. Scaling should be done as fast as possible. (False)

Multiple Choice Questions (15)

  1. What is scaling Agile?
    A) Applying Agile to many teams
    B) One team using Agile
    C) Not using Agile
    Answer: A
  2. What is SAFe?
    A) A comprehensive scaling framework
    B) A simple scaling framework
    C) A game
    Answer: A
  3. What is LeSS?
    A) A comprehensive scaling framework
    B) A simple scaling framework
    C) A game
    Answer: B
  4. What is an ART?
    A) A group of teams in SAFe
    B) A type of Sprint
    C) A meeting
    Answer: A
  5. What is a PI?
    A) A long planning cycle
    B) A short Sprint
    C) A meeting
    Answer: A
  6. What is PI Planning?
    A) A 2-day event
    B) A 15-minute meeting
    C) A one-hour meeting
    Answer: A
  7. What is Scrum of Scrums?
    A) A coordination meeting
    B) A Sprint Planning
    C) A Retrospective
    Answer: A
  8. What is a shared vision?
    A) Common product goal
    B) A type of chart
    C) A meeting
    Answer: A
  9. What is a common mistake?
    A) Scaling too fast
    B) Scaling slowly
    C) Not scaling
    Answer: A
  10. What is a best practice?
    A) Starting small
    B) Starting big
    C) Not starting
    Answer: A
  11. What does LeSS stand for?
    A) Large-Scale Scrum
    B) Lightweight Scrum
    C) Lean Scrum
    Answer: A
  12. What does SAFe stand for?
    A) Scaled Agile Framework
    B) Simple Agile Framework
    C) Scrum Agile Framework
    Answer: A
  13. Why is continuous improvement important?
    A) To keep getting better
    B) To stay the same
    C) To get worse
    Answer: A
  14. What is integration at scale?
    A) Combining work from many teams
    B) One team working alone
    C) No integration
    Answer: A
  15. What is the future of scaling?
    A) Hybrid models and AI
    B) No change
    C) Less Agile
    Answer: A

Matching Exercises

TermMeaning
1. SAFeA. Comprehensive scaling framework
2. LeSSB. Simple scaling framework
3. ARTC. Group of teams in SAFe
4. PID. Long planning cycle
5. Scrum of ScrumsE. Coordination meeting

Answers: 1-A, 2-B, 3-C, 4-D, 5-E

Short Answer Questions

  1. What is scaling Agile?
  2. What is the difference between LeSS and SAFe?
  3. What is an ART and what does it do?
  4. What is a common mistake when scaling Agile?

Scenario-based Exercises

  • Scenario 1: Your company has grown from 1 team to 10 teams. What framework would you recommend and why?
  • Scenario 2: Teams are working on the same product but not coordinating. What practice would you introduce?
  • Scenario 3: Your organisation has lost its Agile culture after scaling. What would you do?

Group Activity

In groups, design a scaled Agile structure for a company with 15 teams. Decide whether to use LeSS or SAFe and explain your choice. Present to the class.

Individual Activity

Research a scaling framework (like SAFe or LeSS) and write a one-page summary of its key features.

Classroom Discussion Questions

  • Why is it harder to scale Agile than to use it in one team?
  • What would you do to keep the Agile culture alive as you scale?
  • What is the most important practice when scaling?

Mini Project

Create a poster comparing LeSS and SAFe. Include their key features, differences, and when to use each one.

Practical Assignment

Talk to a team in a large organisation (or research online) and find out how they coordinate with other teams. Write a short report.

Challenge Exercise

Research how a Nigerian company scales Agile. Write a summary and share with the class.

Quiz Answers

Multiple Choice answers: 1-A, 2-A, 3-B, 4-A, 5-A, 6-A, 7-A, 8-A, 9-A, 10-A, 11-A, 12-A, 13-A, 14-A, 15-A.

True/False answers: 1-F, 2-F, 3-T, 4-T, 5-F.

Key Takeaways

  • Scaling Agile coordinates many teams.
  • SAFe and LeSS are popular scaling frameworks.
  • LeSS is simpler; SAFe is more comprehensive.
  • Start small and keep Agile values.
  • Continuous improvement is essential for scaling.

Preparation for the Next Module

In Module 9, we will learn about Agile Leadership and Culture – how to lead Agile teams and build a culture that supports Agile values. You'll learn about servant leadership, psychological safety, and how to foster a growth mindset. Get ready to become an Agile leader!

10

Module Nine

Module 9: Agile Leadership and Culture

Module Nine: Agile Leadership and Culture – Leading with Heart

Module Introduction

Hello, future leader! πŸ‘‘ In the last eight modules, you learned all the technical and process parts of Agile – Scrum, Kanban, XP, estimation, metrics, and scaling. But there is one thing that makes Agile truly work: leadership and culture. You can have the best framework, but if the culture is bad, it won't work. In this module, we will learn about servant leadership, psychological safety, and how to build a culture that makes Agile thrive. By the end, you'll know how to lead with heart and create a team that loves working together. Let's go!

Learning Objectives

By the end of this module, you will be able to:

  • Understand what Agile leadership is.
  • Describe servant leadership.
  • Explain psychological safety.
  • Build a culture of trust and collaboration.
  • Lead with empathy and a growth mindset.

Warm-up Story: The Chief Who Listened

In a Nigerian village, there was a chief named Oba Ade. He was a good leader – he made decisions and gave orders. But one day, the village had a problem: the harvest was small, and people were hungry. Instead of telling people what to do, Oba Ade gathered everyone and asked, "What do you think we should do?" The villagers shared ideas – some said to plant new crops, others said to dig wells. Oba Ade listened carefully. Together, they created a plan that worked. The harvest improved, and the village thrived. Oba Ade was a servant leader – he listened, supported, and trusted his people. That's what Agile leadership is all about.

Main Lessons

Lesson 1: What is Agile Leadership?

Definition: Agile leadership is a way of leading that focuses on serving the team, empowering people, and creating a culture of trust and collaboration.

Why it is important: Without good leadership, Agile practices are just a checklist. With good leadership, they come alive.

Simple explanation: It's like being a coach who helps the team play better – not a boss who just gives orders.

Real-life example: A manager who asks the team how they can help instead of telling them what to do.

School example: A teacher who guides students instead of just lecturing.

Home example: A parent who supports their child's choices instead of just giving commands.

Nigerian example: A Nigerian team lead who removes obstacles for the team.

Illustration:

  Agile Leader = Supports, empowers, trusts
      

Mini summary: Agile leadership is about supporting and empowering the team.


Lesson 2: Servant Leadership – Leading by Serving

Definition: Servant leadership is a philosophy where the leader's primary goal is to serve the team – to make sure they have what they need to succeed.

Why it is important: When leaders serve, teams feel valued and perform better.

Simple explanation: It's like being a waiter – you make sure everyone has what they need.

Real-life example: A Scrum Master who clears blockers so the team can work.

School example: A teacher who provides resources for students.

Home example: A parent who makes sure the family has everything they need.

Nigerian example: A Nigerian leader who listens to the team before making decisions.

Illustration:

  Servant Leader = Serves the team, not the other way
      

Mini summary: Servant leadership means putting the team's needs first.


Lesson 3: Psychological Safety – Feeling Safe to Speak Up

Definition: Psychological safety is the belief that you won't be punished for speaking up with ideas, questions, or mistakes.

Why it is important: When people feel safe, they share ideas, admit mistakes, and learn together.

Simple explanation: It's like knowing you can ask a question in class without being laughed at.

Real-life example: A team member says, "I made a mistake" – and the team helps fix it instead of blaming.

School example: A student asks a "silly" question and the teacher says, "Good question!"

Home example: A child admits they broke something and the parent says, "It's okay, let's fix it."

Nigerian example: A Nigerian team shares mistakes during retrospective without fear.

Illustration:

  Psychological Safety = Safe to speak up, safe to fail
      

Mini summary: Psychological safety means people feel safe to speak and take risks.


Lesson 4: Why Psychological Safety Matters

Definition: Psychological safety leads to better teamwork, more innovation, and higher performance.

Why it is important: Without it, people hide mistakes and don't share ideas.

Simple explanation: It's like a garden – plants need a safe environment to grow.

Real-life example: Google found that psychological safety was the #1 factor for high-performing teams.

School example: A classroom where students participate actively.

Home example: A family where everyone shares their feelings.

Nigerian example: A Nigerian company that encourages open communication.

Illustration:

  Psychological Safety β†’ Trust β†’ Innovation β†’ High Performance
      

Mini summary: Psychological safety is the foundation of high-performing teams.


Lesson 5: Building Trust – The Currency of Teams

Definition: Trust is the confidence that team members have in each other and in their leader.

Why it is important: Trust makes teams work faster and better – they don't waste time second-guessing.

Simple explanation: It's like knowing your friend will keep a secret – you can rely on them.

Real-life example: A team trusts that everyone will do their part – they don't need to micromanage.

School example: A group trusts that each member will complete their part of a project.

Home example: A family trusts that chores will be done.

Nigerian example: A Nigerian team trusts that everyone will deliver quality work.

Illustration:

  Trust = Believing others will do what they say
      

Mini summary: Trust is the foundation of strong teams.


Lesson 6: Empathy – Understanding Each Other

Definition: Empathy is the ability to understand and share the feelings of another person.

Why it is important: It builds connection and helps leaders support their team.

Simple explanation: It's like putting yourself in someone else's shoes.

Real-life example: A leader notices a team member is stressed and offers support.

School example: A teacher sees a student is struggling and helps them.

Home example: A parent listens when a child is upset.

Nigerian example: A Nigerian leader shows understanding when a team member faces challenges.

Illustration:

  Empathy = Understanding others' feelings
      

Mini summary: Empathy helps leaders connect with their team.


Lesson 7: Growth Mindset – Learning from Mistakes

Definition: A growth mindset is the belief that abilities can be developed through hard work and learning.

Why it is important: It encourages learning, resilience, and continuous improvement.

Simple explanation: It's like saying "I can't do this yet" instead of "I can't do this."

Real-life example: A team member fails at a task, learns, and tries again.

School example: A student studies harder after a bad grade.

Home example: A child learns to ride a bike after falling.

Nigerian example: A Nigerian team learns from a failed Sprint and improves.

Illustration:

  Growth Mindset = "I can learn and improve"
      

Mini summary: A growth mindset embraces learning and improvement.


Lesson 8: Fostering a Culture of Collaboration

Definition: A collaborative culture is one where people work together, share ideas, and help each other.

Why it is important: Collaboration leads to better solutions and stronger teams.

Simple explanation: It's like a potluck – everyone brings something, and the meal is better.

Real-life example: Teams pair program, share knowledge, and help each other.

School example: Students work together on group projects.

Home example: Family members cook together.

Nigerian example: A Nigerian team holds regular knowledge-sharing sessions.

Illustration:

  Collaboration = Working together to achieve more
      

Mini summary: Collaboration creates better solutions and stronger teams.


Lesson 9: Feedback – The Breakfast of Champions

Definition: Feedback is information about performance that helps people improve.

Why it is important: Without feedback, people don't know how they're doing.

Simple explanation: It's like a mirror – it helps you see yourself clearly.

Real-life example: A team member gives constructive feedback in a retrospective.

School example: A teacher gives feedback on a student's essay.

Home example: A parent tells a child they did a good job.

Nigerian example: A Nigerian team gives open, honest feedback during retrospectives.

Illustration:

  Feedback = Helps you grow and improve
      

Mini summary: Feedback is essential for growth and improvement.


Lesson 10: Giving and Receiving Feedback Well

Definition: Good feedback is specific, timely, and kind. When receiving feedback, listen and learn.

Why it is important: Done well, feedback builds trust. Done poorly, it breaks it.

Simple explanation: It's like giving a gift – it must be wrapped with care.

Real-life example: "Your code was clear – next time, try to add more comments."

School example: "Your essay was good – work on your grammar next time."

Home example: "Thanks for cleaning – next time, please also vacuum."

Nigerian example: A Nigerian team gives constructive feedback in a kind way.

Illustration:

  Good Feedback: Specific, Kind, Timely
      

Mini summary: Feedback should be given and received with care and respect.


Lesson 11: Leading by Example – Be the Change

Definition: Leading by example means modelling the behaviour you want to see in your team.

Why it is important: People do what they see – not what they're told.

Simple explanation: It's like being a role model – you show others how to act.

Real-life example: A leader who arrives on time, follows Agile practices, and treats everyone with respect.

School example: A teacher who is organised and punctual.

Home example: A parent who models kindness and patience.

Nigerian example: A Nigerian leader who participates in ceremonies and sets an example.

Illustration:

  Lead by Example = Do what you want others to do
      

Mini summary: Leading by example inspires others to follow.


Lesson 12: Empowering the Team – Trust Them

Definition: Empowering means giving team members the authority and responsibility to make decisions.

Why it is important: Empowered teams are more motivated and creative.

Simple explanation: It's like giving someone the steering wheel – they can drive.

Real-life example: A team decides how to implement a feature without the leader telling them how.

School example: A student chooses their project topic.

Home example: A child decides what to wear.

Nigerian example: A Nigerian leader trusts the team to make decisions.

Illustration:

  Empower = Give people the power to decide
      

Mini summary: Empowering the team builds trust and motivation.


Lesson 13: Coaching vs. Directing – Guide, Don't Command

Definition: Coaching means guiding people to find their own solutions. Directing means telling them what to do.

Why it is important: Coaching builds capability; directing builds dependency.

Simple explanation: It's like teaching someone to fish instead of giving them a fish.

Real-life example: A leader asks, "What do you think we should do?" instead of saying, "Do this."

School example: A teacher helps a student solve a problem instead of giving the answer.

Home example: A parent helps a child think through a problem.

Nigerian example: A Nigerian leader coaches team members to grow.

Illustration:

  Coaching: Guiding to find answers
  Directing: Giving answers
      

Mini summary: Coaching helps people grow; directing creates dependency.


Lesson 14: Building an Agile Culture – A Shared Mindset

Definition: An Agile culture is a way of thinking and behaving that supports Agile values – collaboration, learning, and improvement.

Why it is important: Culture is the soil in which Agile grows – without it, nothing works.

Simple explanation: It's like the air you breathe – it affects everything.

Real-life example: A company where people feel safe, speak openly, and learn from mistakes.

School example: A school where students are encouraged to ask questions.

Home example: A family where everyone is heard and respected.

Nigerian example: A Nigerian company that values open communication.

Illustration:

  Agile Culture = Trust, Safety, Learning, Collaboration
      

Mini summary: An Agile culture supports collaboration, learning, and growth.


Lesson 15: The Leader's Role in Culture

Definition: Leaders are the guardians of culture – they set the tone and model the behaviours they want to see.

Why it is important: Without leadership attention, culture degrades.

Simple explanation: It's like a gardener – you must tend the garden for it to bloom.

Real-life example: A leader who celebrates learning from mistakes.

School example: A principal who encourages innovation.

Home example: A parent who models respect and empathy.

Nigerian example: A Nigerian leader who embodies Agile values.

Illustration:

  Leader as Gardener = Nurtures the culture
      

Mini summary: Leaders are responsible for nurturing the culture.


Key Vocabulary (simple definitions)

  • Agile Leadership: Leading by serving and empowering.
  • Servant Leadership: Putting the team's needs first.
  • Psychological Safety: Feeling safe to speak up.
  • Trust: Confidence in others.
  • Empathy: Understanding others' feelings.
  • Growth Mindset: Belief that you can learn and improve.
  • Collaboration: Working together.
  • Feedback: Information to improve.
  • Coaching: Guiding people to find their own solutions.
  • Agile Culture: A mindset that supports Agile values.

Important Concepts

  • People first: Agile is about people, not processes.
  • Trust is key: Without trust, nothing works.
  • Safety matters: People need to feel safe to speak up.
  • Culture is leadership: Leaders shape the culture.

Step-by-Step Explanations

How to Create Psychological Safety

  1. Listen actively – give people your full attention.
  2. Encourage questions – celebrate curiosity.
  3. Normalise mistakes – talk about learning from them.
  4. Don't blame – focus on solutions, not fault.
  5. Be vulnerable – share your own mistakes.

How to Give Good Feedback

  1. Be specific – say exactly what you observed.
  2. Be kind – deliver it with respect.
  3. Be timely – give feedback close to the event.
  4. Focus on behaviour, not personality.
  5. Offer suggestions for improvement.

Teacher Notes

  • Use the chief story to explain servant leadership.
  • Discuss psychological safety in the classroom.
  • Role-play giving and receiving feedback.
  • Emphasise that culture is built daily.

Parent Tips

  • Model empathy and trust at home.
  • Encourage your child to speak up and ask questions.
  • Celebrate mistakes as learning opportunities.

Interesting Facts & Did You Know?

  • Did you know? Google's Project Aristotle found that psychological safety was the #1 factor for team success.
  • Interesting: Servant leadership was first described by Robert K. Greenleaf in 1970.
  • Did you know? Companies with strong cultures outperform those without.
  • Nigeria: Nigerian leaders are increasingly adopting servant leadership styles.

Remember This

  • Agile leadership is about serving the team.
  • Psychological safety is essential for high performance.
  • Trust and empathy build strong teams.
  • Feedback helps people grow.
  • Leaders shape the culture.

Common Mistakes

  • Commanding instead of coaching: Telling people what to do instead of guiding.
  • Ignoring culture: Focusing only on processes.
  • Not giving feedback: People don't know how to improve.
  • Not listening: Leaders who don't hear the team.

Best Practices

  • Lead by example.
  • Create psychological safety.
  • Give and receive feedback regularly.
  • Empower the team.
  • Nurture the culture daily.

Illustrations & Diagrams

The Leadership Iceberg

  β”Œβ”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”
  β”‚  What you see: Skills, results, processes   β”‚
  β”‚  ────────────────────────────────────────────│
  β”‚  What you don't see: Trust, safety, culture β”‚
  β””β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”˜
      

The Culture Cycle

  Leadership β†’ Culture β†’ Behaviour β†’ Results β†’ Leadership
      

Comparison Tables

Servant Leader vs Traditional Leader

Servant LeaderTraditional Leader
Serves the teamTeam serves the leader
Listens firstSpeaks first
EmpowersControls
Builds trustDemands obedience
CoachesCommands

Good vs Bad Feedback

Good FeedbackBad Feedback
SpecificVague
KindHarsh
TimelyDelayed
Focuses on behaviourAttacks personality
Offers suggestionsJust criticises

End-of-Module Summary

Incredible work! You have learned what makes Agile truly work – leadership and culture. You now understand servant leadership, psychological safety, trust, empathy, and the growth mindset. You also know how to give and receive feedback, lead by example, and empower your team. Remember, Agile is not just about processes – it's about people. The best frameworks are useless without a great culture. In the final module, Module 10, we will put everything together and discuss Becoming a Certified Agile Developer – your journey to certification and beyond. Keep leading with heart!

Frequently Asked Questions (10)

  1. What is Agile leadership? Leading by serving and empowering.
  2. What is servant leadership? Putting the team's needs first.
  3. What is psychological safety? Feeling safe to speak up.
  4. What is trust? Confidence in others.
  5. What is empathy? Understanding others' feelings.
  6. What is a growth mindset? Belief that you can learn.
  7. What is feedback? Information to improve.
  8. What is coaching? Guiding to find solutions.
  9. What is an Agile culture? A mindset supporting Agile values.
  10. What is the leader's role? Nurturing the culture.

Review Questions (15)

  1. What is Agile leadership?
  2. What is servant leadership?
  3. What is psychological safety?
  4. Why is psychological safety important?
  5. What is trust?
  6. What is empathy?
  7. What is a growth mindset?
  8. What is collaboration?
  9. What is feedback?
  10. How should you give feedback?
  11. What does it mean to lead by example?
  12. What does empowering the team mean?
  13. What is the difference between coaching and directing?
  14. What is an Agile culture?
  15. What is the leader's role in culture?

Fill-in-the-Blank Exercises

  1. _______ leadership means putting the team's needs first. (Servant)
  2. _______ safety means feeling safe to speak up. (Psychological)
  3. _______ is confidence in others. (Trust)
  4. _______ is understanding others' feelings. (Empathy)
  5. A _______ mindset means believing you can learn. (growth)
  6. _______ helps people grow and improve. (Feedback)

True or False Exercises

  1. Agile leadership is about commanding the team. (False)
  2. Psychological safety means people can speak up without fear. (True)
  3. Trust is not important for teams. (False)
  4. Feedback should only be negative. (False)
  5. Leaders shape the culture. (True)

Multiple Choice Questions (15)

  1. What is servant leadership?
    A) Serving the team
    B) Being served by the team
    C) Not leading
    Answer: A
  2. What is psychological safety?
    A) Feeling safe to speak up
    B) Feeling scared
    C) Not speaking
    Answer: A
  3. What is trust?
    A) Confidence in others
    B) Doubt in others
    C) Indifference
    Answer: A
  4. What is empathy?
    A) Understanding others' feelings
    B) Ignoring others' feelings
    C) Focusing on yourself
    Answer: A
  5. What is a growth mindset?
    A) Believing you can learn
    B) Believing you can't learn
    C) Not caring
    Answer: A
  6. What is collaboration?
    A) Working together
    B) Working alone
    C) Not working
    Answer: A
  7. What is feedback?
    A) Information to improve
    B) Criticism only
    C) Praise only
    Answer: A
  8. What does it mean to lead by example?
    A) Model the behaviour
    B) Tell others what to do
    C) Do nothing
    Answer: A
  9. What does empowering the team mean?
    A) Giving them authority
    B) Taking authority away
    C) Ignoring them
    Answer: A
  10. What is coaching?
    A) Guiding to find solutions
    B) Giving answers
    C) Not helping
    Answer: A
  11. What is an Agile culture?
    A) A mindset supporting Agile
    B) A process
    C) A tool
    Answer: A
  12. What is the leader's role in culture?
    A) To nurture it
    B) To ignore it
    C) To change it daily
    Answer: A
  13. Why is psychological safety important?
    A) It helps teams perform
    B) It makes people scared
    C) It doesn't matter
    Answer: A
  14. How should you give feedback?
    A) Kindly and specifically
    B) Harshly and vaguely
    C) Never
    Answer: A
  15. What is the most important thing in Agile?
    A) People and culture
    B) Processes
    C) Tools
    Answer: A

Matching Exercises

TermMeaning
1. Servant LeadershipA. Putting team first
2. Psychological SafetyB. Safe to speak up
3. TrustC. Confidence in others
4. EmpathyD. Understanding others
5. Growth MindsetE. Belief you can learn

Answers: 1-A, 2-B, 3-C, 4-D, 5-E

Short Answer Questions

  1. What is servant leadership?
  2. What is psychological safety and why is it important?
  3. How can you give good feedback?
  4. What is the leader's role in building culture?

Scenario-based Exercises

  • Scenario 1: A team member makes a mistake and is afraid to speak up. How can you build psychological safety?
  • Scenario 2: A leader is always giving orders and not listening. What would you advise them?
  • Scenario 3: Your team is not collaborating well. What steps can you take to improve?

Group Activity

In groups, role-play a scenario where a leader gives feedback to a team member. Practice giving it kindly and specifically. Then switch roles.

Individual Activity

Reflect on a leader you admire. What qualities do they have? Write a short essay on how they exemplify Agile leadership.

Classroom Discussion Questions

  • What does psychological safety look like in your classroom?
  • Why is it hard to give feedback sometimes?
  • How can you build trust in a team?

Mini Project

Create a "Culture Manifesto" for your ideal team. List 5 values that would create a great culture.

Practical Assignment

Over the next week, practice giving feedback to someone in a kind and specific way. Write a short reflection on how it went.

Challenge Exercise

Research a Nigerian leader known for servant leadership. Write a summary and share with the class.

Quiz Answers

Multiple Choice answers: 1-A, 2-A, 3-A, 4-A, 5-A, 6-A, 7-A, 8-A, 9-A, 10-A, 11-A, 12-A, 13-A, 14-A, 15-A.

True/False answers: 1-F, 2-T, 3-F, 4-F, 5-T.

Key Takeaways

  • Agile leadership is about serving the team.
  • Psychological safety is essential for high performance.
  • Trust and empathy build strong teams.
  • Feedback helps people grow.
  • Leaders shape the culture.

Preparation for the Next Module

In Module 10, we will bring everything together and discuss Becoming a Certified Agile Developer. You'll learn about the certification process, how to prepare for the exam, and what to expect in your Agile career. You're almost there – keep going!

11

Module Ten

Module 10: Becoming a Certified Agile Developer

Module Ten: Becoming a Certified Agile Developer – Your Journey Ahead

Module Introduction

Hello, future Certified Agile Developer! πŸŽ“ You have made it to the final module of this course. Over the past nine modules, you have learned everything – from Agile values and Scrum to Kanban, XP, user stories, estimation, metrics, scaling, and leadership. Now it's time to put it all together and talk about becoming certified. Certification is like a stamp of approval that shows the world you know Agile. In this module, we will learn about the certification process, how to prepare, and what comes after. Let's finish this journey strong!

Learning Objectives

By the end of this module, you will be able to:

  • Understand what Agile certification is.
  • Identify the main certification bodies.
  • Know how to prepare for the exam.
  • Understand the benefits of certification.
  • Plan your Agile career path.

Warm-up Story: The Journey of the Young Developer

In a Nigerian village, there was a young girl named Chioma who loved building things. She learned to build websites and apps, but she wanted to prove her skills. She heard about Agile and studied it for months. She practiced with her team, failed, learned, and improved. Finally, she took an exam and became a Certified Agile Developer. Her certificate was like a key that opened doors – she got a great job, earned respect, and helped her team build amazing products. Chioma's journey shows that certification is not the end – it's the beginning of a new chapter.

Main Lessons

Lesson 1: What is Agile Certification?

Definition: An Agile certification is a credential that shows you have knowledge and skills in Agile practices and frameworks.

Why it is important: It validates your knowledge, builds trust, and can help you get hired.

Simple explanation: It's like a driver's license for Agile – it shows you know how to drive.

Real-life example: A company hires someone with a Certified Scrum Master (CSM) certification.

School example: A student earns a certificate after finishing a course.

Home example: A parent gets a certificate after completing a training.

Nigerian example: A Nigerian developer gets certified to stand out in the job market.

Illustration:

  Certification = Proof of your Agile knowledge
      

Mini summary: Agile certification validates your skills and knowledge.


Lesson 2: Popular Agile Certifications

Definition: There are many Agile certifications – some focus on Scrum, others on general Agile, and others on specific roles.

Why it is important: Knowing which certification to pursue helps you focus your efforts.

Simple explanation: It's like choosing a subject to study – you pick what fits your goals.

Real-life example: Certifications like CSM, SAFe Agilist, and PMI-ACP are popular.

School example: A student chooses a major in college.

Home example: A parent chooses a course to improve their skills.

Nigerian example: A Nigerian professional chooses the certification that fits their role.

Illustration:

  Popular Certifications:
  - CSM (Certified Scrum Master)
  - SAFe Agilist
  - PMI-ACP (Agile Certified Practitioner)
  - Certified Agile Developer (CAD)
      

Mini summary: There are many Agile certifications – choose the one that fits your goals.


Lesson 3: Certified Scrum Master (CSM)

Definition: CSM is a certification for Scrum Masters – people who help teams follow Scrum.

Why it is important: It shows you can coach a Scrum team effectively.

Simple explanation: It's like a badge for Scrum coaches.

Real-life example: A Scrum Master gets CSM certification to advance their career.

School example: A student leads a group project and gets a leadership badge.

Home example: A parent learns to guide family meetings.

Nigerian example: A Nigerian Scrum Master gets CSM to boost their credentials.

Illustration:

  CSM = Scrum Master certification
      

Mini summary: CSM is a popular certification for Scrum Masters.


Lesson 4: SAFe Agilist – Scaling Certification

Definition: SAFe Agilist is a certification for leading Agile transformations at scale using the SAFe framework.

Why it is important: It shows you can guide large organisations in adopting Agile.

Simple explanation: It's like a certification for being a "big picture" Agile leader.

Real-life example: A leader gets SAFe Agilist to lead a company-wide Agile transformation.

School example: A principal gets a certification for leading school-wide changes.

Home example: A parent leads a large family project.

Nigerian example: A Nigerian leader gets SAFe Agilist to scale Agile in their company.

Illustration:

  SAFe Agilist = Leading Agile at scale
      

Mini summary: SAFe Agilist is for leaders scaling Agile in organisations.


Lesson 5: PMI-ACP – Agile Certified Practitioner

Definition: PMI-ACP is a certification from PMI (Project Management Institute) that covers many Agile frameworks.

Why it is important: It shows you know multiple Agile methods – Scrum, Kanban, XP, and more.

Simple explanation: It's like a general Agile certification – you know a bit of everything.

Real-life example: A project manager gets PMI-ACP to show their Agile versatility.

School example: A student gets a certificate for completing a broad course.

Home example: A parent learns multiple ways to manage tasks.

Nigerian example: A Nigerian professional gets PMI-ACP to stand out.

Illustration:

  PMI-ACP = Broad Agile certification
      

Mini summary: PMI-ACP covers multiple Agile frameworks.


Lesson 6: What You'll Learn in a Certification Exam

Definition: Certification exams test your knowledge of Agile values, principles, frameworks, and practices.

Why it is important: You need to study and understand the material to pass.

Simple explanation: It's like a final exam – you review everything you learned.

Real-life example: The exam includes questions on Scrum roles, events, artifacts, and more.

School example: A student reviews all topics for a final exam.

Home example: A parent reviews a course before the test.

Nigerian example: A Nigerian professional studies Agile guides and practice tests.

Illustration:

  Exam Topics:
  - Agile values and principles
  - Scrum, Kanban, XP
  - User stories
  - Estimation and planning
  - Metrics and reporting
      

Mini summary: Certification exams test your Agile knowledge across many areas.


Lesson 7: How to Prepare for the Exam

Definition: Preparation means studying the material, taking practice tests, and gaining practical experience.

Why it is important: Good preparation increases your chances of passing.

Simple explanation: It's like training for a race – you practice to be ready.

Real-life example: A candidate reads the Scrum Guide, takes practice tests, and works on Agile teams.

School example: A student studies, does practice questions, and gets extra help.

Home example: A parent takes a prep course before the exam.

Nigerian example: A Nigerian professional joins an Agile study group.

Illustration:

  Preparation Steps:
  1. Study the material
  2. Take practice tests
  3. Gain practical experience
  4. Join a study group
      

Mini summary: Preparation involves study, practice, and experience.


Lesson 8: The Certification Exam – What to Expect

Definition: The exam is usually multiple-choice, with a time limit. You need a certain score to pass.

Why it is important: Knowing what to expect reduces anxiety.

Simple explanation: It's like a quiz – but longer and more serious.

Real-life example: The CSM exam has 50 questions and you need 37 to pass.

School example: A final exam with 50 questions and a passing score.

Home example: A driving test with a passing score.

Nigerian example: A Nigerian candidate takes the exam online or at a test centre.

Illustration:

  Exam Format:
  - Multiple-choice
  - Time-limited
  - Passing score required
      

Mini summary: Certification exams are multiple-choice with a passing score.


Lesson 9: Maintaining Your Certification – Continuous Learning

Definition: Many certifications require you to maintain them by earning credits or retaking the exam.

Why it is important: It ensures you stay current with Agile practices.

Simple explanation: It's like renewing your driving license – you need to prove you're still good.

Real-life example: CSM requires renewal every 2 years.

School example: A student needs to pass yearly tests.

Home example: A parent attends workshops to stay updated.

Nigerian example: A Nigerian professional attends Agile meetups to earn credits.

Illustration:

  Maintenance:
  - Earn continuing education credits
  - Attend Agile events
  - Stay updated on new practices
      

Mini summary: Certifications require ongoing learning to stay valid.


Lesson 10: The Benefits of Certification

Definition: Benefits include better job opportunities, higher pay, and more respect from peers.

Why it is important: Certification opens doors and boosts your career.

Simple explanation: It's like having a golden ticket – it gives you access to better opportunities.

Real-life example: A certified professional gets promoted faster.

School example: A student with a certificate gets a scholarship.

Home example: A parent gets a better job after certification.

Nigerian example: A Nigerian certified professional earns a higher salary.

Illustration:

  Benefits:
  - Better jobs
  - Higher pay
  - More respect
  - Career growth
      

Mini summary: Certification brings many career benefits.


Lesson 11: Common Myths About Certification

Definition: Myths include "Certification is easy," "It's not worth it," and "You need to be an expert."

Why it is important: Myths can discourage people – but they're not true.

Simple explanation: It's like believing a rumour – you need to check the facts.

Real-life example: Some people think certification is only for managers – but developers also benefit.

School example: Some students think a certificate is too hard – but with study, it's possible.

Home example: A parent thinks they're too old for certification – but you're never too old to learn.

Nigerian example: A Nigerian professional thinks certification is only for large companies – but it helps everyone.

Illustration:

  Myths:
  ❌ It's easy
  ❌ It's not worth it
  ❌ Only experts can pass
      

Mini summary: Don't believe myths – certification is achievable and valuable.


Lesson 12: Planning Your Agile Career Path

Definition: Your career path includes your goals, certifications, and roles – from developer to Agile coach.

Why it is important: Having a plan helps you focus and achieve your goals.

Simple explanation: It's like having a map for a journey – you know where you're going.

Real-life example: A developer plans to become a Scrum Master, then an Agile Coach.

School example: A student plans to study, get certified, and then get a job.

Home example: A parent plans to improve their skills and get a promotion.

Nigerian example: A Nigerian professional plans their Agile career with certifications.

Illustration:

  Career Paths:
  Developer β†’ Scrum Master β†’ Agile Coach β†’ Enterprise Agile Leader
      

Mini summary: Plan your Agile career path with certifications and goals.


Lesson 13: Continuing Education – Never Stop Learning

Definition: Continuing education means always learning new things – through courses, books, events, and practice.

Why it is important: Agile is always evolving – you must evolve with it.

Simple explanation: It's like watering a plant – you must keep nurturing it.

Real-life example: A professional reads Agile books, attends conferences, and tries new practices.

School example: A student continues learning even after graduation.

Home example: A parent takes online courses to stay updated.

Nigerian example: A Nigerian professional attends Agile meetups and webinars.

Illustration:

  Continuing Education:
  - Read books
  - Attend events
  - Take courses
  - Practice with teams
      

Mini summary: Never stop learning – Agile is always evolving.


Lesson 14: The Agile Community – You Are Not Alone

Definition: The Agile community is a global network of people who share Agile knowledge and support each other.

Why it is important: You can learn from others, share your experiences, and get support.

Simple explanation: It's like a club where everyone helps each other.

Real-life example: Agile meetups, online forums, and conferences.

School example: A study group where students help each other.

Home example: A parent joins a community of parents learning skills.

Nigerian example: A Nigerian professional joins an Agile group in Lagos.

Illustration:

  Community = Support, Learning, Connection
      

Mini summary: The Agile community supports your growth and learning.


Lesson 15: Your Next Steps – The Journey Continues

Definition: Your next steps include choosing a certification, studying, taking the exam, and continuing to grow.

Why it is important: This is just the beginning – your Agile journey continues.

Simple explanation: It's like finishing a chapter – the story continues.

Real-life example: A developer decides to get CSM certification and joins an Agile team.

School example: A student graduates and starts their career.

Home example: A parent completes a course and applies the skills.

Nigerian example: A Nigerian professional starts their Agile journey with a certification plan.

Illustration:

  Next Steps:
  1. Choose a certification
  2. Study and prepare
  3. Take the exam
  4. Continue learning
      

Mini summary: Your Agile journey continues – take the next step today!


Key Vocabulary (simple definitions)

  • Certification: Proof of your Agile knowledge.
  • CSM: Certified Scrum Master.
  • SAFe Agilist: Certification for scaling Agile.
  • PMI-ACP: Agile certification from PMI.
  • Exam: Test to earn certification.
  • Preparation: Studying and practicing for the exam.
  • Maintenance: Keeping your certification valid.
  • Career Path: Your planned journey in Agile.
  • Continuing Education: Ongoing learning.
  • Community: Network of Agile professionals.

Important Concepts

  • Certification validates your skills: It proves you know Agile.
  • Preparation is key: Study and practice to pass.
  • Learning never stops: Agile evolves – you must too.
  • Community matters: Connect with other Agile professionals.

Step-by-Step Explanations

How to Get Certified in Agile

  1. Choose a certification (e.g., CSM, SAFe Agilist, PMI-ACP).
  2. Study the material (read books, guides, take courses).
  3. Take practice tests to assess your knowledge.
  4. Register for the exam.
  5. Take the exam and aim for a passing score.
  6. Maintain your certification through continuing education.

How to Prepare for the Exam

  1. Review the exam syllabus.
  2. Read the official guides (e.g., Scrum Guide for CSM).
  3. Take online practice tests.
  4. Join a study group or attend a prep course.
  5. Gain practical experience on an Agile team.

Teacher Notes

  • Encourage students to research certifications that interest them.
  • Discuss the value of certification in the job market.
  • Emphasise that experience is just as important as certification.
  • Share resources for certification preparation.

Parent Tips

  • Help your child research certification options.
  • Encourage them to take practice tests and study.
  • Celebrate their achievement when they get certified.

Interesting Facts & Did You Know?

  • Did you know? The first Scrum certification was offered in 2002.
  • Interesting: Over 1 million people are certified in Agile worldwide.
  • Did you know? Certified professionals earn 20-30% more on average.
  • Nigeria: Agile certification is growing in popularity in Nigeria.

Remember This

  • Certification proves you know Agile.
  • Popular certifications: CSM, SAFe Agilist, PMI-ACP.
  • Prepare by studying and practicing.
  • Maintain your certification with continuous learning.
  • Your Agile journey continues – keep growing.

Common Mistakes

  • Not studying enough: Underestimating the exam.
  • Choosing the wrong certification: Pick one that fits your goals.
  • Not maintaining certification: Letting it expire.
  • Focusing only on certification: Experience is equally important.

Best Practices

  • Choose a certification that aligns with your role.
  • Study consistently, not just before the exam.
  • Gain practical experience on Agile teams.
  • Maintain your certification with ongoing learning.
  • Connect with the Agile community.

Illustrations & Diagrams

Certification Path

  β”Œβ”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”
  β”‚  1. Choose Certification                              β”‚
  β”‚       β”‚                                               β”‚
  β”‚  2. Study and Prepare                                 β”‚
  β”‚       β”‚                                               β”‚
  β”‚  3. Take the Exam                                     β”‚
  β”‚       β”‚                                               β”‚
  β”‚  4. Get Certified                                     β”‚
  β”‚       β”‚                                               β”‚
  β”‚  5. Maintain and Grow                                 β”‚
  β””β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”˜
      

Agile Career Ladder

  Junior Developer
       β”‚
       β–Ό
  Senior Developer
       β”‚
       β–Ό
  Scrum Master / Agile Lead
       β”‚
       β–Ό
  Agile Coach
       β”‚
       β–Ό
  Enterprise Agile Leader
      

Comparison Tables

Popular Agile Certifications

CertificationFocusBest For
CSMScrumScrum Masters, Developers
SAFe AgilistScaling AgileLeaders, Coaches
PMI-ACPMultiple frameworksProject Managers
Certified Agile DeveloperGeneral AgileDevelopers, Professionals

Certification vs Experience

CertificationExperience
Proves you know the theoryShows you can apply it
Helps you get hiredHelps you succeed on the job
Earned through examsEarned through practice

End-of-Module Summary

Congratulations! πŸŽ‰ You have reached the end of this course. You now know everything about becoming a Certified Agile Developer. You learned what certification is, the popular certifications, how to prepare, and what to expect. You also learned about your career path, the importance of continuing education, and the Agile community. Remember, certification is a milestone – not the destination. Keep learning, keep practicing, and keep growing. You have the knowledge and skills to succeed. Go out there and make a difference!

Frequently Asked Questions (10)

  1. What is Agile certification? Proof of Agile knowledge.
  2. What is CSM? Certified Scrum Master.
  3. What is SAFe Agilist? Certification for scaling Agile.
  4. What is PMI-ACP? Agile certification from PMI.
  5. How do I prepare for the exam? Study, practice, and gain experience.
  6. Is certification important? It helps with career opportunities.
  7. How long is certification valid? Usually 2 years.
  8. How do I maintain my certification? Through continuing education.
  9. What is the Agile community? A network of Agile professionals.
  10. What is the next step? Choose a certification and start preparing!

Review Questions (15)

  1. What is Agile certification?
  2. Name three popular Agile certifications.
  3. What is CSM?
  4. What is SAFe Agilist?
  5. What is PMI-ACP?
  6. How do you prepare for the exam?
  7. What is the exam format?
  8. How do you maintain your certification?
  9. What are the benefits of certification?
  10. What is a common myth about certification?
  11. What is an Agile career path?
  12. Why is continuing education important?
  13. What is the Agile community?
  14. What is the next step after this course?
  15. What is the most important thing to remember?

Fill-in-the-Blank Exercises

  1. _______ is proof of your Agile knowledge. (Certification)
  2. _______ stands for Certified Scrum Master. (CSM)
  3. _______ is a certification for scaling Agile. (SAFe Agilist)
  4. _______ is an Agile certification from PMI. (PMI-ACP)
  5. You need to _______ your certification with continuing education. (maintain)
  6. The _______ community supports your Agile journey. (Agile)

True or False Exercises

  1. Certification is not important for developers. (False)
  2. CSM is a certification for Scrum Masters. (True)
  3. You don't need to maintain your certification. (False)
  4. The Agile community helps you learn. (True)
  5. Certification is the end of learning. (False)

Multiple Choice Questions (15)

  1. What is Agile certification?
    A) Proof of Agile knowledge
    B) A type of Agile framework
    C) A game
    Answer: A
  2. What does CSM stand for?
    A) Certified Scrum Master
    B) Certified Scrum Manager
    C) Certified Scrum Mentor
    Answer: A
  3. What is SAFe Agilist?
    A) Certification for scaling Agile
    B) A type of Scrum
    C) A game
    Answer: A
  4. What is PMI-ACP?
    A) Agile certification from PMI
    B) A type of Kanban
    C) A game
    Answer: A
  5. How do you prepare for the exam?
    A) Study and practice
    B) Don't study
    C) Guess
    Answer: A
  6. What is the exam format?
    A) Multiple-choice
    B) Essay
    C) Oral
    Answer: A
  7. How do you maintain your certification?
    A) Continuing education
    B) Do nothing
    C) Retake the exam every year
    Answer: A
  8. What is a benefit of certification?
    A) Better job opportunities
    B) More work
    C) Less pay
    Answer: A
  9. What is a common myth?
    A) Certification is too hard
    B) Certification is easy
    C) Certification is free
    Answer: A
  10. What is an Agile career path?
    A) Developer to Agile Coach
    B) Staying in one role
    C) No career path
    Answer: A
  11. Why is continuing education important?
    A) Agile evolves
    B) It's fun
    C) It's not important
    Answer: A
  12. What is the Agile community?
    A) A network of professionals
    B) A type of certification
    C) A game
    Answer: A
  13. What is the next step?
    A) Choose a certification
    B) Stop learning
    C) Forget everything
    Answer: A
  14. What is the most important thing?
    A) Keep learning and growing
    B) Get certified and stop
    C) Ignore Agile
    Answer: A
  15. What does certification prove?
    A) You know Agile
    B) You are an expert
    C) You are a manager
    Answer: A

Matching Exercises

TermMeaning
1. CSMA. Certified Scrum Master
2. SAFe AgilistB. Scaling Agile certification
3. PMI-ACPC. Agile certification from PMI
4. CertificationD. Proof of knowledge
5. CommunityE. Network of professionals

Answers: 1-A, 2-B, 3-C, 4-D, 5-E

Short Answer Questions

  1. What is Agile certification?
  2. Name two popular Agile certifications.
  3. How do you prepare for the certification exam?
  4. What is the next step after this course?

Scenario-based Exercises

  • Scenario 1: You want to become a Scrum Master. Which certification would you pursue?
  • Scenario 2: Your company wants to scale Agile across 10 teams. Which certification would you recommend?
  • Scenario 3: You have been working as a developer for 2 years. You want to advance your career. What certification would you choose?

Group Activity

In groups, research a certification (CSM, SAFe, PMI-ACP, etc.). Create a presentation on what it covers, the exam format, and how to prepare. Present to the class.

Individual Activity

Create a personal "Agile Career Plan." Include your goals, the certifications you want, and a timeline. Share with the class.

Classroom Discussion Questions

  • Why is certification valuable in the job market?
  • What challenges might you face when preparing for certification?
  • How can the Agile community help you?

Mini Project

Create a "Certification Preparation Guide" for future students. Include study tips, resources, and practice questions.

Practical Assignment

Find a practice test for a certification (CSM, PMI-ACP, etc.) and take it. Write a short reflection on your score and areas for improvement.

Challenge Exercise

Research the cost and requirements of a certification. Write a summary and share with the class.

Quiz Answers

Multiple Choice answers: 1-A, 2-A, 3-A, 4-A, 5-A, 6-A, 7-A, 8-A, 9-A, 10-A, 11-A, 12-A, 13-A, 14-A, 15-A.

True/False answers: 1-F, 2-T, 3-F, 4-T, 5-F.

Key Takeaways

  • Agile certification proves your knowledge.
  • Popular certifications include CSM, SAFe Agilist, and PMI-ACP.
  • Prepare by studying, practicing, and gaining experience.
  • Certification brings career benefits.
  • Your Agile journey is continuous – keep learning.

Preparation for the Next Course

Congratulations on completing the Certified Agile Developer course! πŸŽ‰ You now have a deep understanding of Agile, Scrum, Kanban, XP, and the skills to become certified. If you enjoyed this course, consider exploring other courses like Advanced Agile Leadership, Scaling Agile in the Enterprise, or Agile Coaching and Mentoring. The world of Agile is vast – keep learning, keep growing, and remember: the best developers are those who never stop learning. Good luck on your journey!

πŸ† Get Certified

πŸ”’

Earn this certificate

Every lesson is already free to read. Sign up, pass the exam, and unlock Practice Tools plus a verified certificate with your name on it β€” ₦4,000/month.

πŸŽ“ Sign Up & Unlock for ₦4,000/month
πŸ› οΈ Practice Tools
Hands-on simulators & labs - subscription required.
β†’
🎯 Internship Tasks
Real-world tasks to build your portfolio - try them free for 7 days, no card required.
β†’