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

  Agile = Small steps + Feedback + Improvement
      

  Waterfall: Plan → Build → Test → Finish (risky)
  Agile: Plan → Build a little → Test → Improve → Repeat
      

  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
      

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

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

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

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

  12 Principles = How to be Agile in practice.
      

  Early delivery → Feedback → Improve → Deliver more
      

  Change is welcome – it means we are learning.
      

  Frequent delivery = less risk, more feedback.
      

  Business + Developers = Better products
      

  Motivated teams → Great products
      

  Face-to-face > Written messages
      

  Reflect → Adjust → Improve → Repeat
      

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

Agile Values vs Traditional Values

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

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!

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

  Scrum = Roles + Events + Artifacts
      

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

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

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

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

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

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

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

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

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

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

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

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

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

  Scrum Cycle:
  Sprint Planning → Work (Daily Scrums) → Sprint Review → Sprint Retrospective → Repeat
      

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

Scrum Events Overview

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

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!

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

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

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

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

  Independent = Can be built separately
      

  Negotiable = Can be discussed and changed
      

  Valuable = Adds value to the user or business
      

  Estimable = Can be estimated for effort
      

  Small = Can be completed in one Sprint
      

  Testable = Can be tested to confirm it works
      

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

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

  Backlog Refinement = Keeping the backlog clean and ready
      

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

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

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

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

User Story vs Acceptance Criteria

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

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!

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

  Kanban Board:
  ┌──────────┬────────────┬──────────┐
  │  To Do   │ In Progress │   Done   │
  ├──────────┼────────────┼──────────┤
  │ Task A   │  Task C    │ Task B   │
  │ Task D   │  Task E    │ Task F   │
  └──────────┴────────────┴──────────┘
      

  Kanban (Japanese) = Visual Signal
      

  Kanban Board Columns:
  Backlog → To Do → In Progress → Review → Done
      

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

  WIP Limit: 3
  ┌────────────┐
  │ In Progress│ (max 3)
  ├────────────┤
  │ Task 1     │
  │ Task 2     │
  │ Task 3     │
  └────────────┘
      

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

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

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

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

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

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

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

  Scrumban = Scrum + Kanban
      

  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
      

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

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

When to Use Kanban vs Scrum

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

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!

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

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

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

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

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

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

  CI Flow:
  Code → Push → Build → Run Tests → Notify if failed
      

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

  Refactoring = Clean up code, keep behaviour the same
      

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

  Collective Ownership = Everyone can change any code
      

  Simple Design = Build what you need, nothing more
      

  Planning Game:
  Customer says what is important → Team estimates → Plan
      

  On-Site Customer = Customer is always available to the team
      

  Continuous Improvement = Always find ways to do better
      

  XP in Action:
  TDD → Pair Programming → CI → Refactoring → Repeat
      

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 Practices Overview

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

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!

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

  Estimation = Predicting effort (not time!)
      

  Planning = Deciding what to do and when
      

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

  Hours = Varies by person
  Story Points = Stable, team-based
      

  Fibonacci:
  1, 2, 3, 5, 8, 13, 21...
      

  Velocity = Average points per Sprint
      

  Velocity = (Sprint 1 + Sprint 2 + Sprint 3) / 3
      

  Sprint Planning:
  1. Decide Sprint Goal
  2. Select stories from backlog
  3. Break stories into tasks
  4. Commit to the Sprint
      

  Capacity = Available time - (holidays, meetings, etc.)
      

  Release Plan:
  Sprint 1: Features A, B
  Sprint 2: Features C, D
  Sprint 3: Features E, F
  → Release after Sprint 3
      

  Cone of Uncertainty:
  Start: ±50% uncertainty
  Middle: ±25%
  End: ±10%
      

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

  Sprint Goal: Clear, focused, achievable
      

  Adapting = Responding to change
      

  Planning Process:
  1. Estimate stories (points)
  2. Calculate velocity
  3. Plan Sprint
  4. Plan release
  5. Adapt as needed
      

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

Estimation Techniques

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

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!

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

  Metrics = Numbers that show how your team is doing
      

  Metrics → Insights → Improvements
      

  Velocity = Average points per Sprint
      

  Burndown Chart (simplified):
  Points
    ↑
  20 |  ●
  15 |  ●
  10 |  ●
   5 |  ●
   0 └────────────────→ Day
      Mon Tue Wed Thu Fri
      

  Burnup Chart (simplified):
  Points
    ↑
  20 |          ●
  15 |        ●
  10 |      ●
   5 |    ●
   0 |  ●
      └────────────────→ Day
      Mon Tue Wed Thu Fri
      

  Cycle Time = Time from start to finish
      

  Throughput = Tasks completed per period
      

  Cumulative Flow Diagram (simplified):
  Tasks
    ↑
  10 │  To Do
  8  │  In Progress
  6  │  Done
  4  │
  2  │
  0 └────────────────→ Time
      

  Lead Time = Time from request to delivery
      

  Sprint Review = Demo + Metrics + Feedback
      

  Retrospective = Review metrics + Plan improvements
      

  Mistakes:
  - Comparing velocity across teams
  - Using metrics as a weapon
  - Focusing on vanity metrics
      

  Metrics → Identify problems → Make changes → Measure again
      

  Dashboard:
  ┌───────────────────────────────┐
  │  Velocity: 20                 │
  │  Cycle Time: 2 days           │
  │  Throughput: 10 tasks/week    │
  └───────────────────────────────┘
      

  Metrics Culture = Data + Transparency + Improvement
      

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

Cycle Time vs Lead Time

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

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!

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

  One Team → Many Teams → Need to coordinate
      

  Challenges:
  - Communication
  - Coordination
  - Shared vision
  - Keeping Agile culture
      

  SAFe Levels:
  Team → Program → Large Solution → Portfolio
      

  LeSS: One Product Backlog, Many Scrum Teams
      

  LeSS: Simple, minimal
  SAFe: Comprehensive, structured
      

  ART = Agile Release Train (Teams working together)
      

  PI = Program Increment (8-12 weeks)
      

  PI Planning: 2-day event, all teams together
      

  Scrum of Scrums = Team reps meet to coordinate
      

  Shared Vision = Everyone knows where we're going
      

  Integration = Putting pieces together
      

  Continuous Improvement = Always getting better together
      

  Mistakes:
  - Scaling too fast
  - Losing the culture
  - Overemphasis on tools
      

  Best Practices:
  - Start small
  - Keep values alive
  - Foster communication
      

  Future: Hybrid models, AI, continuous learning
      

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

Scaling Frameworks Overview

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

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!

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

  Agile Leader = Supports, empowers, trusts
      

  Servant Leader = Serves the team, not the other way
      

  Psychological Safety = Safe to speak up, safe to fail
      

  Psychological Safety → Trust → Innovation → High Performance
      

  Trust = Believing others will do what they say
      

  Empathy = Understanding others' feelings
      

  Growth Mindset = "I can learn and improve"
      

  Collaboration = Working together to achieve more
      

  Feedback = Helps you grow and improve
      

  Good Feedback: Specific, Kind, Timely
      

  Lead by Example = Do what you want others to do
      

  Empower = Give people the power to decide
      

  Coaching: Guiding to find answers
  Directing: Giving answers
      

  Agile Culture = Trust, Safety, Learning, Collaboration
      

  Leader as Gardener = Nurtures 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

Good vs Bad Feedback

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

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!

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

  Certification = Proof of your Agile knowledge
      

  Popular Certifications:
  - CSM (Certified Scrum Master)
  - SAFe Agilist
  - PMI-ACP (Agile Certified Practitioner)
  - Certified Agile Developer (CAD)
      

  CSM = Scrum Master certification
      

  SAFe Agilist = Leading Agile at scale
      

  PMI-ACP = Broad Agile certification
      

  Exam Topics:
  - Agile values and principles
  - Scrum, Kanban, XP
  - User stories
  - Estimation and planning
  - Metrics and reporting
      

  Preparation Steps:
  1. Study the material
  2. Take practice tests
  3. Gain practical experience
  4. Join a study group
      

  Exam Format:
  - Multiple-choice
  - Time-limited
  - Passing score required
      

  Maintenance:
  - Earn continuing education credits
  - Attend Agile events
  - Stay updated on new practices
      

  Benefits:
  - Better jobs
  - Higher pay
  - More respect
  - Career growth
      

  Myths:
  ❌ It's easy
  ❌ It's not worth it
  ❌ Only experts can pass
      

  Career Paths:
  Developer → Scrum Master → Agile Coach → Enterprise Agile Leader
      

  Continuing Education:
  - Read books
  - Attend events
  - Take courses
  - Practice with teams
      

  Community = Support, Learning, Connection
      

  Next Steps:
  1. Choose a certification
  2. Study and prepare
  3. Take the exam
  4. Continue learning
      

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

Certification vs Experience

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

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!