Scrum

From Wikipedia, a generic description:

“Scrum is an agile (author’s note: an iterative, incremental and short loop cycle development work) framework for developing, delivering, and sustaining complex products, with an initial emphasis on software development, although it has been used in other fields including research, sales, marketing and advanced technologies. It is designed for teams of ten or fewer members, who break their work into goals that can be completed within timeboxed iterations, called sprints, no longer than one month and most commonly two weeks. The Scrum Team track progress in 15-minute time-boxed daily meetings, called daily scrums. At the end of the sprint, the team holds sprint review, to demonstrate the work done, and sprint retrospective to continuously improve.”

../_images/scrum_framework.png

Global view of Scrum process and component from scrum.org

From there, all definitions are “SPL biaised” as the team has its own needs and habits that could differ from bare Scrum/Agile.

Process

SPL team defined its rules and habits as this:

Backlog

The backlog is a place were everyone in the team is allowed to freely add cards. It’s used to describe tasks todo, desired features and so-on.

This is the source of cards used while Sprint Planning

Tools

Kanban

A Kanban board for SPL is available on Notion. All project are shown on one board and label are used to keep it nice and tight.

Many views exists to show only personal cards and filters exists to make advanced search.

Communication

Microsoft Teams is used to handle most of meetings, record Standups and even share some joke or any work-unrelated thing that a team-member want to share, using a dedicated channel ;)

Code repo

GitLab handles Continuous Integration, issues and host documentation on GitLab Pages.

Misc

Sprints Retrospective are done with RetroTool and then saved on Microsoft Teams Scrum channel.

During Sprints Planning, card points are define using an app, Scrum Time (Google Play Store or Apple App Store).

Note

We don’t use points anymore as it doesn’t fit well with our organization. We have a more flexible planning, allowing anyone to move tasks from backlog (or any status).

Sprints

As said, SPL Sprints are 3 weeks long. A meeting is defined a the end to make the Review, then the Retrospective and finally the Planning.

Review

The Review intends to let each team member make a quick explanation or demo of the work done. It must not take too much time but in the last Retrospective we decided to take as much time as necessary as the team has grown-up quite a bit.

Retrospective

In order to improve continuously, a retrospective is done. A few minutes are given to write thoughts in three categories Liked, Learned and Lacked.

Then a vote is done, each participant got 3 points to distribute as he please.

The most voted card(s) are then reviewed and a small brainstorm is done to find how to improve on this point.

Planning

Before planning, each team member must have written a few cards into the backlog. Then it’s a discussion about which tasks are needed and will be done during the next sprint.

Daily Standups

Every morning on 11:50 the team connect to the dedicated Teams channel (Daily Standup) and/or gather around a laptop and give a short speech while standing. This remind everyone to stay concise. The meeting is recorded so that any absent person could catchup.

Typically each member got 1-2 minutes to speak about:

  • what he did the day before

  • what he’ll do this day

  • did obstacles exists

All of this focussed on projects. Sometimes the team speaks a bit about other things (vacations planning, teaching, …) and it’s tacitly accepted as it keep everyone informed.

At the end of the standup, a quick look is given to the team Kanban to keep it updated and giving opportunity to everyone of staying aware of projects evolutions.

Sometimes we take some time (think 5-10min, if more is needed we tend to chose another time-frame) after the standup to show something, discuss a specific topic of anything. If one want to do such a discussion, generally a message is posted in the Teams channel to ask/inform the colleague.

Sprint Cards

A card must be clear and concise with a definition of done and a definition of ready as well as an assignee and label(s).

A card contains a story which tell the goals and acceptance criterias as well as a description of the task. An example:

  • Explicit title: “Search for an available taxi”

  • Narrative phrase: “As persona, I want feature, so that function.” -> “As a customer, I want to see all nearby taxis, so that I can select one.”

  • Acceptance criteria: “Only display available taxis”, “Show a picture of the car”, “Sort by nearest”

Definition of Ready

To be Ready, a card must have:

  • A story written with described format

  • Acceptance criteria, clear and functional

  • A Points estimation

  • If relevant, any external resource (link, diagram, document)

  • Valid for the team

Note

As we tend to use points less and less, this feature could be omitted.

Definition of Done

To be Done, a card must be:

  • output must be saved (GitLab for code, OneDrive for other documentation)

  • if relevant, testing/validation must have been performed (CI, proof-reading)

  • if relevant, documented

  • accepted in Sprint Review

Points

Each card take a certain amount of time and effort to be completed. In order to get an idea of a task complexity, a scale of Points is given.

This is not a 1:1 time conversion/estimation

As time goes on, the team improves on knowing the complexity of a given task and on how many Points it could do in a Sprint. Points value is an internal metric and can’t be compared to other teams as it rely on member vision of what a 1 Point task is.

Each card is so estimated by the team using this app. Please configure the deck as the picture below shows.

../_images/deck.png

Deck configuration used by SPL team

The processus of Points giving consist in:

  • the card owner describe the card and answer questions

  • if needed a discussion occurs

  • each team member choose a value in its deck

  • when ready, show all choice at the same time

  • if diverging, highest and lowest explain their choice and the process repeat

  • when converging (either all the same value or a range acceptable by all), the estimation is fixed

Experience shown that roughly 5 minutes per card were needed, so it was decided to take 15-45 minutes per sprint to evaluate cards in backlog.

Scrum