Agile Scrum 🚀

Agile Scrum (Mêlée au rugby) is one of the most widely used Agile methodologies (méthodes agiles). This is a kind of incremental method (wiki) that is repeating small cycles (sprints/iterations).

A long time ago, the V-Model (Cycle en V) model (an extension of the Waterfall model) was the most commonly used methodology. But, it wasn't flexible, the client often had to wait a long time, and the product may not have been what they wanted.

As this is an incremental method, we add functionalities incrementally. When an iteration ends, there is a demonstration for the client, who will give feedback. It helps determine the focus of the next iteration.

Other Agile methodologies: XP (Extreme programming), Kanban.

The Agile manifesto (Manifeste Agile), signed in 2001, defines the guidelines for Agile projects: Agile Manifesto

💪 Values and principles 💪

Agile is a mindset (état d'esprit) 🤓, and Scrum is a framework (cadre de travail~=methodology) 🛠. You need to learn both 🚀.

Agile-Scrum is based on 3 pillars (transparency, inspection, adaptation), and 5 values

  • Courage: face your problems, and do what must be done, don't hide bugs under the carpet (pas de 🐛 sous le tapis)
  • Focus: concentrate on the sprint goal
  • Commitment: be committed to your work
  • Respect: be respectful to others
  • Openness: be open to changes or evolutions

Agile methodologies are based on 12 principles and 4 values (principles and values (FR), principles (EN) and values (EN)). My summary is

  • to do everything to make your client happy 😊
  • allow changing the specifications ✍️
  • frequently deliver working software 💻
  • make sure that users and devs are working together 😏
  • always strive to do better 🧐
  • have a stable development speed 👌
  • interact face-to-face 🗣️

Roles

Scrum involves 3 roles in a team

👑 Product Owner (PO)

The client interacts with the Product owner. They must understand the business/market requirements, and organize the tasks so that the client gets what they want.

They will redact (and update) the Product backlog. Others may create entries in the backlog too, but they should notify or ask the product owner first.


🤵 Development team (Dev. team)

They are the people doing the work. This is usually a team of 3 to 9 people, but some are adapting Scrum for bigger teams. Notice that it is Development, not Developers. You can have graphics/UX designers, sound engineers, artists, or testers, along with the developers. Anyway, we can consider all of them as developers in the end, so you may use both.

🌠 Scrum master (SM)

The Scrum master makes sure that the developers (the product owner, and the company too) are only focusing on their jobs, and not on applying Scrum. He should organize (or sometimes facilitate) meetings, support the team, manage the tools, do reporting, deal with blockers, and "timeboxing" (a meeting shouldn't last more than it was supposed to) so that the project is going smoothly.

The Scrum Master is an expert in Scrum, and they must ensure that Scrum is used properly, but if the team agrees on changing something, they must be open to changes (as they follows the principles and values of Scrum).

Random notes

(1) Do not ask the intern to grab some cakes, or some coffee; that's the Scrum master's job 🤩 (joke aside, they may).

(2) The Scrum master may be a member of the dev team, and it may rotate through the team.

(3) The Scrum master is not a project manager/leader (chef de projet). The project manager oversees/controls the project, while the Scrum master actively works on improving the workflow of the project.

📜 Scrum 📜

The development is made of iterations, a repetition of cycles, called sprints (=iteration). The result of your sprint is usually called an increment. A sprint is made of 4 ceremonies (rituels).

  1. Sprint Planning: when starting a sprint
  2. Daily Scrum: daily meeting
  3. Sprint review: in the end, demonstration to the client
  4. Sprint retrospective: usually at the end, look for improvements

Usually, a sprint lasts 2 to 4 weeks. Once you pick a duration, you shouldn't change it (unless you have a good reason).

A sprint is considered a project as a whole, so you have to write tests and documentation during the sprint. You will do the same as you are doing for the project and add functionalities one after another until you reach your goal.

Sprint 0

This is the first sprint, but it's labeled as Sprint 0, because this is not a real sprint and this is before the first sprint. You will set up everything during this sprint, and create the workflow of the application. It means, you have to

  • create the folders (ex: sep-bothc, headers, etc.)
  • create files such as README.md, LICENSE, etc.
  • write your guidelines/style guide/... (if you've got one)
  • pick your tools (ex: git, trello, ...)
  • set up your tools (ex: create repository, master/main?)
  • set up the rules (ex: branches/...)
  • ...

And write some code, but only the bare minimum so that everyone can start their task without meddling with/stopping everyone else (ex: create the Main file, maybe create the data-related files, so that all of you know what data is manipulated, etc.).

1. Sprint Planning

The main goal of the Sprint Planning is to decide your Sprint goal. Your Sprint goal is what you want to achieve at the end of the sprint.

  • Involves: PO, SM, Dev. team
  • Duration: up to 4 hours/4 weeks

The Product Owner is proposing a goal, and the items of the product backlog that you may do. The dev team is picking items (=>value for the client, effort), explicitly defining when they are considered to be "done" (doc? tests?), in the sprint backlog. You need to have a clear idea of what makes the sprint successful, and how you will achieve the sprint goal. They will redact two of Scrum's artifacts:

🪀️ Product backlog

The Product backlog, is a sort of project specification (cahier des charges). This is a list of tasks. You must add features that the client requested in a specific format, called User Stories or US for short.

User Stories and Epics

A User Story (US) is a text describing a task from the point of view of a user. Ideally, we would only have user stories, but there are always some other stories (technical/...) that are popping up. An Epic is a group of stories (mostly US) that are "similar" (ex: all stories related to the user management). There are stories about:

  • features (functional)
  • bugs (technical)
  • tests (technical)
  • technical debt (technical): this is what you have to do before starting to improve the code (refactor, use constants...)
  • actions (technical): changing your way of doing things (=usually a reflection from a retrospective)

In a user story, we must know the reason, the goal, the value, and an estimation of the cost/value for the person needing this task to be done. Ex:

Example (template): "As a <type of user>, I <want to do something/goal>, so that <a reason/benefit>.".

Note: to add a technical story, you need to explain and persuade the product owner that this will help

Note: you will usually deliver the stories when the epic is done.

Tip: give colors to your stories according to their kind (ie: feature, bugs, etc.).

Note: You can see an epic as the result of a succession of stories, and a group of epics is making what we call an initiative.

Prioritizing using MoSCoW

You will most likely use the MoSCoW notation to prioritize US.

  • M: Must have this US (mandatory)
  • S: Should have this US (expected)
  • C: Could have this US (ideally)
  • W: Would have this US (out of scope)

You should ask the client about priorities and suggest priorities too, since some tasks may be too hard/useless if done in the first increment. You must take into account the value for the client.

Estimation of the complexity

You need to evaluate how complex a task is (or how much effort it will require). We are not evaluating the duration like in non-agile projects.

  • You may compare tasks and sort them by difficulty.
  • You can assign a value from a fixed list (0, 1/2, 1, 2, 3, 5, 8, 13, 20, 40, 100, ?, inf.) to each task. The average or median value may be used as an answer.

If you have outliers (valeurs abérantes), such as everyone giving a rating of "10", except for one person who gave "5" and another who gave "20", it would be beneficial to inquire about the reasons behind their choices. They may have considered something that others overlooked.

You should learn from your previous estimates. You may pick a previous task and use it as a reference.

Example of Product Backlog as a table

You may create a table, in which each row is a story. You may group them by epics if you want. As for the columns, here are some ideas

  • # or ID: ID of the story
  • Title or Title+Description: the story
  • The priority
  • The importance, estimated with
    • An estimation of the complexity
    • An estimation of the value for the client
  • Some notes
  • The Sprint: the one in which you completed this story (empty if you didn't)
  • The Epic: if this story belongs to an epic
  • The dependencies between US/Epics
  • Acceptance tests: how will the Product Owner (or ...) test that the feature is working
Notes

  • Entries in the product backlog are also called items.

  • Sometimes, the backlog may become too big, so you may remove the less important tasks, and label them as "out of scope" (such as Could/Would, or tasks that do not impact the sprint goal if they are removed)

  • Reviewing the backlog is sometimes called backlog grooming (or refinement)

  • Usually, the Product Owner and the Scrum master prepare the Product backlog before the meeting.

🏢 Sprint backlog

The Sprint backlog is a list of tasks that the dev team took from the product backlog. These are the tasks that they are planning to do during the sprint. Tasks are split into smaller tasks, each ideally taking a few hours and up to one day to be marked as "done".

Each developer takes on tasks according to their capacity. This is the sum of the complexity of the tasks they picked up in the previous sprint.

Whiteboard

We are using the famous whiteboard, with the following columns

  • To-do (À faire): what has to be done
  • In-progress (En cours): working on it
  • Done (Terminé/Fini): done

Your goal is to move all of your cards to Done. You should add to each card the name of the person who will do the task.

Source: scrum.org

You may have a few more columns before "Done"

  • Review (Revue/Relecture): someone else is checking your task
  • Tests (Tests): testing the feature
  • Documented (Documentation): working on the documentation
  • Canceled/Blocked (Annulée): you won't/can't continue a task
Whiteboard (Online)

Here are some free tools

How to split tasks into smaller tasks?

Here is an example with the main page of a desktop application

  • make the frame without any content (close, minimize, etc.)
  • make the toolbar
  • display the main content
  • deal with the translations
  • make the app responsive (=adapting itself to the size of the screen)
  • ...

2. Daily Scrum or standup/stand-up

Check the progress. What each one did yesterday, what they are planning to do today. Identify blockers and challenges. The purpose is informative, a sort of coffee break 🍵 (pause café). If you don't drink coffee, maybe chatting while playing a game might be a new way of approaching this (ball ⚾, cards 🃏, etc.). Everyone is supposed to stand up (rester debout) 👍 as this shouldn't last long.

  • You can use Round Robin: everyone is answering three questions (yesterday? today? blockers?)

  • You can use the Board-based method (walking the board): from the right to the left, ask for information about each task.

  • Some utilize a prop, such as a ball ⚾, which is held up by the one talking. They pass it on to the next person with the condition that the recipient should not be their immediate neighbor in the circle.

  • Some are using a token given to the one talking (ex: ball ⚾). They will give it to the next person with the constraint of the next one not being their neighbor in the circle.

  • Involves: SM, Dev. team, PO?
  • Duration: up to 15 minutes

🪙 My two cents 🪙

As a Scrum master, try to relay as much as possible to your group. It may be a good idea to have a one-on-one talk with each member, once a day/[...]. This may help them think of new ways of doing something, improve their documentation/comments, think of new tests, and hopefully broaden both your and their horizons.

3. Sprint review

At the end of the iteration, you must demonstrate to the client (and sometimes your team) what you did, and the items you completed (also talk about what you planned, but didn't make). Take note of what the client wants to review in the product backlog.

Each developer may demonstrate what they did (and why?), but do not make it too long, like 5 minutes per person. Do not forget to talk about key metrics: you are making a software/website/... for customers, check that it is usable/...

  • Involves: PO, SM, Dev. team, the client/users
  • Duration: up to 4 hours/4 weeks

Some organizations do a weekly demo with the team, so that everyone knows what the others are doing, understands a bit more about what they need to do, and keeps track of what the client wants.

4. Sprint retrospective

At the end of the iteration, identify the areas for improvement. Find out what didn't work well and, of course, what worked well.

  • tools (outils/logiciels)
  • peoples
  • directives (règles: écriture du code, comportement, etc.)
  • processes (organisation)
  • ...
  • Involves: PO (may not be here), SM, Dev. team
  • Duration: up to 3 hours/4 weeks

You must select one thing and focus on it. Focusing on one thing means making sure that I least one thing will improve per sprint. You might write an action plan of what to do.

Note: You can do this retrospective in the middle of a sprint.

Metrics

The following are ways to check the progress or get key indicators of your project.

  • R.O.T.I (return of time invested)

Ask your team, how much a meeting was useful

  • 5: excellent
  • 4: above average/good
  • 3: average/ok
  • 2: useful
  • 1: useless
  • Velocity

The velocity is the capacity of your team. This is not a value comparable to other teams/projects. This is the sum of the complexity of the tasks your team took on. You should use it to not take too many stories (both per person and per group). This value will converge after some iterations. You should usually keep a 10% margin (meetings, technical debt, quality, etc.).

You may use a burn-down chart (or a burn-up chart) to represent this graphically.

👻 To-do 👻

Stuff that I found, but never read/used yet.

Concepts

  • Initiatives
  • Themes
  • T-Shirt Size Estimation
  • Scrum release planning
  • DevOps
  • Delegation Poker
  • Vision Statement
  • Volere Requirements
  • Product roadmap
  • Product requirements documents (PRD)