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.”
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:
Sprint duration is 3 weeks
Standups are on 11:50 and recorded (thanks to Retrospectives upgrades)
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.
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.