# 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.).

1. Write User Stories following this format: "As a [user], I want [action] so that [benefit]."

2. 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

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.

• 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:

When to Report a Need?

Who Should Be Notified of a Technical Need?

Sprint Review

When ? How much time ?

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

When ? How much time ?

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.