# Exercise: Agile Project Management - Nutrition App for CPAM

Project Context

The CPAM (French Health Insurance) wants to develop a nutrition application to help its beneficiaries adopt a healthier diet and prevent nutrition-related diseases (diabetes, obesity, etc.). This application will offer personalized recommendations, meal tracking, health challenges, and food composition information.

Objective of the Exercise

Practice Agile project management principles by organizing and planning the development of the application using the Scrum methodology.

🛠 Use Trello for this exercise.

1. Team Formation and Roles

• Divide the class into several teams (4 to 6 students per team).

• Each team must define the following roles:
  • Product Owner (PO): Defines user needs and prioritizes features.
  • Scrum Master (SM): Facilitates team work and ensures Agile principles are followed.
  • Developers: Work on implementing the defined features.
  • Testers (if applicable): Verify the quality and compliance of developments.

2. Definition of the Product Backlog

Each team must:

1. Identify the key features of the application (e.g., user registration, nutritional recommendations, meal tracking, integration with connected devices, etc.).
   • User registration and authentication.
   • Generation of personalized nutritional recommendations.
   • Meal tracking with manual input and image recognition.
   • Integration with connected devices (scales, smartwatches, etc.).
   • Implementation of health challenges and personalized reminders.
   • Dashboard for progress tracking and meal history.
   • Access to a database of healthy recipes tailored to the user's needs.
   • List of food items with their composition.

2. Write User Stories following this format: "As a [user], I want [action] so that [benefit]."
   • "As a user, I want to create an account and log in so that I can access my personalized data."
   • "As a user, I want to receive tailored nutritional recommendations so that I can improve my diet."
   • "As a user, I want to record my daily meals so that I can track my nutrition and receive personalized advice."
   • "As a user, I want to synchronize the app with my smartwatch so that I can automatically integrate my health data."
   • "As a user, I want to participate in nutrition challenges so that I can stay motivated and improve my eating habits."
   • "As a user, I want to access a database of healthy recipes so that I can easily prepare balanced meals."
   • "As a user, I want to know the composition of food items."

3. Prioritize these User Stories based on their value to the user.
   • High Priority: Registration/authentication, nutritional recommendations, meal tracking.
   • Medium Priority: Synchronization with connected devices, health challenges.
   • Low Priority: Recipe database, detailed meal history.

3. Creating a SCRUM Board

• Columns should be filled progressively as work advances.

• create the story cards
  • Example of a Story Card

    📝 Title: Meal Logging in the Application

    📌 User Story:

    “As a user, I want to log my meals so that I can track my nutrition.”

    ✅ Acceptance Criteria to consider the Story as completed:

    • The user can enter the meal name, quantity, and date.
    • The application validates the data before saving.
    • Meals are stored and displayed in the history.

    🎯 Priority: High

    ⏳ Estimation: 5 points

    🔗 Dependencies: Requires the meal database.

    💬 Notes: Verify error handling in case of incorrect input.

Scrum Board Example:

• Blocked (⛔): Tasks pending resolution (e.g., a critical bug).

• Code Review (👀): Tasks requiring validation before testing.

📌 The Sprint Backlog contains the User Stories selected for the sprint.

⚡ Important: A User Story is too broad to be completed at once → break it down into tasks.

📌 The "To Do" column contains the technical tasks necessary to complete the User Stories.

Incremental

The incremental approach in Scrum means that the application evolves gradually with each sprint by delivering features usable by the end user. Here's how we see this incremental aspect in the exercise:

1. Defining the Increment in the Exercise

🔹 In each Sprint, the team develops a functional part of the product.

🔹 Each sprint ends with a usable deliverable (e.g., an interface, a working API).

🔹 The application progressively expands over the sprints with new features.

✅ Each sprint adds a functional block that improves the product.

✅ We don't build an entire product in six months, but we deliver usable parts every two weeks.

✅ We continuously improve instead of planning everything upfront.

Iterative

Iterative → We improve existing features by incorporating user feedback.

Concrete example in our project:

1. Sprint 1: First version of meal entry. ✅

2. Sprint 2: Adding synchronization with connected devices (incremental). ✅

3. Sprint 3: Improving the meal entry design and fixing bugs (iterative). ✅

3. Sprint Planning

• Define a 2-week Sprint.

• Select the User Stories to be developed in the Sprint Backlog.

• Choose a set of User Stories that can be completed within 2 weeks.

• Prioritize those that provide immediate value to the user.

• Break down User Stories into smaller, achievable tasks.

• Estimate the associated tasks using a method like Planning Poker.

Planning Poker Estimation

• Each team member assigns an estimate in complexity points (e.g., Fibonacci: 1, 2, 3, 5, 8...).

• The team discusses estimation discrepancies and adjusts if necessary.

• The goal is to have a realistic estimation of the work achievable in 2 weeks.

What is Planning Poker?

Planning Poker is an Agile estimation method used to assess the effort required to complete a User Story. It helps the team reach a consensus on task complexity while avoiding individual biases.

1. Objective of Planning Poker

✅ Obtain a collective and consensual estimation of a User Story's complexity.

✅ Prevent a single person from influencing others with their estimation.

✅ Encourage discussion and understanding of tasks.

2. How Planning Poker Works

💡 Materials: A set of Planning Poker cards (or an online tool). Each card represents an effort value based on the Fibonacci sequence:

1, 2, 3, 5, 8, 13, 21, 34, … (sometimes including ∞ and ? for uncertainty).

📌 Step 1: Presenting the User Story

• The Product Owner explains the User Story to the team.

• The team asks questions to fully understand what needs to be done.

📌 Step 2: Choosing Estimations

• Each team member secretly selects a card representing their effort estimation.

• Estimates consider:
  🔹 Technical complexity.
  🔹 Development effort.
  🔹 Possible uncertainties and risks.
  

📌 Step 3: Revealing the Cards

• All members simultaneously reveal their chosen cards.

📌 Step 4: Discussing Discrepancies

• If everyone votes the same value, it is confirmed.

• If there are large differences (e.g., a 3 and a 13), a discussion follows:
  • Why do some think it's easy?
  • Why do others think it's difficult?
  • Are there underestimated technical challenges or dependencies?

📌 Step 5: Re-estimation (if necessary)

• After discussion, the team votes again until reaching a consensus.

📌 Step 6: Assigning the Final Estimation

• The final estimation is recorded in the Sprint Backlog.

3. Examples of Planning Poker in Action

Example 1: Easy Estimation

🔹 User Story: "As a user, I want to change my password."

🔹 Team votes: All vote “2”.

✅ Immediate consensus → The story is estimated at 2 points.

Example 2: Disagreement on Estimation

🔹 User Story: "As a user, I want to receive recommendations based on my meal history."

🔹 Team votes:

• Dev A → 5

• Dev B → 8

• Dev C → 13

• Dev D → 5

🔹 Discussion:

• Dev C explains that the AI system is more complex than expected.

• Dev A assumed it was just a simple SQL query.

• After discussion, the team agrees on 8. ✅

🔹 Examples of User Stories estimated using Planning Poker:

How Does a Break Card Work in Planning Poker?

🔹 Each team member has a Break Card in addition to number cards.

🔹 During voting, a member can play this card instead of a number.

🔹 If one or more Break Cards appear:

• The team takes a short break (5-10 min).

• The User Story is re-discussed to clarify uncertainties.

• The team can then re-estimate after the break.

4. Simulation of Scrum Events

During the exercise, each team will simulate Scrum ceremonies:

Daily Stand-up (5 minutes per team)

Each member shares their progress, blockers, and goals for the day.

• Introduce a change during the Sprint to simulate an evolving customer need.

• Add a technical or budgetary constraint to force backlog adaptation.

• Perform tasks (on paper) and note successes, failures, difficulties, and needs.

• Add a new requirement:
  • Example: AI needs for image recognition.

    ➡ Action: The Scrum Master organizes a discussion with the team and the PO to determine if:

    • The team can train internally.
    • They need to hire an expert or purchase a third-party solution.
    • They can work around the issue with a simpler solution.
  • 💬 A developer: "We need access to CPAM databases, but we don’t have permissions yet."
    • ➡ Action: The PO contacts CPAM’s technical lead to expedite access.

When to Report a Need?

💡 As early as possible to avoid delays:

✅ During a Daily Scrum: If a developer discovers a technical gap blocking progress.

Who Should Be Notified of a Technical Need?

🔹 Scrum Master: To assess if it’s a blocker and facilitate team discussions.

🔹 Product Owner (PO): To discuss the impact on the backlog and product value.

🔹 Development Team: To determine if an internal solution can be found.

Sprint Review

Presentation of completed developments.

• Happens right after the Sprint ends (e.g., if the Sprint lasts 2 weeks, the Sprint Review takes place on the last day of the second week).

• The duration depends on Sprint size but typically lasts 30 minutes to 1 hour for a 2-week Sprint.

Typical Sprint Review Flow:

1. Presentation of completed work: Demonstration of new features or improvements.

2. Stakeholder feedback: Discussion on alignment with user needs and expectations.

3. Discussion on product evolution: Possible adjustments to the Product Backlog based on feedback.

4. Preparation for the next Sprint: Adjusting priorities for the next phase of the project.

Sprint Retrospective

Discussion on what worked well and what could be improved.

• Takes place before the next Sprint starts, so improvements can be applied immediately.

• Duration varies by Sprint length, but usually 30 minutes to 1 hour for a 2-week Sprint.

Typical Sprint Retrospective Flow:

1. What went well? 🌟
   • Identify positive aspects and Sprint successes.

2. What could be improved? 🔍
   • Discuss difficulties and obstacles encountered.

3. What actions should be implemented to improve? ✅
   • Define concrete actions to apply in the next Sprint.

1. Where to Document Sprint Review Feedback? 📝

📌 In a shared tracking document or space (e.g., Notion, Confluence, Google Docs, Trello, Jira).

📌 Directly in the Product Backlog if adjustments are needed.

📌 In a Sprint Review Report.

A good way to track retrospective feedback is to use a continuous improvement board, for example, in Trello or Notion:

6. Learning Objectives

• The relevance of User Stories and their prioritization.

• Sprint management and Scrum ceremonies.

• The quality of deliverables and the clarity of the demonstration.

• Experiencing Agile project management in a real-world scenario.

• Working as a team.

• Understanding the challenges of iterative and collaborative development.

• Understanding and applying Agile project management.

• Experimenting with Scrum roles and ceremonies.

• Learning to work in a team and organize the development of a digital product.

Learning Objectives:

• Understand and apply Agile project management.

• Experiment with Scrum roles and ceremonies.

• Learn to work in a team and organize the development of a digital product.