Do you know the 8 Steps to Scrum?
Scrum is easier than it seems, we’ll explain how in these 8 simple steps.
Print out the SSW 8 Steps to Scrum PDF and put it on your “War Room” wall.
1. Initial Meeting
In the Initial Meeting, the Product Owner explains the product vision. The Developers think about the Architecture needed and how long they will need to come up with an estimate.
2. Backlog Construction
The next step is Backlog Construction, also known as a Specification Review. The Developers propose a high-level software architecture and a to-do list called the Product Backlog. The required features are broken down into Product Backlog Items (PBIs for short).
These PBIs are estimated and, before a dollar figure is presented, a buffer is added for generic tasks such as DevOps, Testing, Bug Fixes, Project Management, etc.
This is also when the Product Owner 1st defines the Product Goal (aka the “why” of the project), although this can and should be refined throughout the project.
A quick note, there are only 3 roles in a Scrum Team, The Product Owner (the boss), the Scrum Master (a kind of project manager), and the Developers (who do the work).
3. Sprint Planning
The Sprint Planning session is for the Developers to focus on the subset of the Product Backlog that they think they can complete in the next Sprint, (which is most commonly a 2-week time-box).
The Product Owner puts the PBIs into priority order and makes sure the top ones have enough detail to be worked on. The Developers then pulls PBIs from the top of the Backlog and commits to delivering as much as they forecast they can, in the coming Sprint.
The Developers and Product Owner together then define the Sprint goal, (aka the “why” of the Sprint).
4. Sprint
The Developers work on features in priority order, having done a Daily Scrum and sending ‘Done’ emails once the ‘Definition of Done’ is met. A task board is often used. During this process, the team also refines items in the Product Backlog to ensure they conform to the ‘Definition of Ready’.
5. Product Increment
Each Sprint is a potentially shippable Product Increment, and with good DevOps, including automation of deployment and testing, this can be done on a “PBI by PBI” basis. This means each feature worked on can be in production as soon as it is finished.
6. Product Feedback
Product Feedback will then come in. Some will be bugs, and some will be small changes that can be added to the current Sprint. Other suggestions should be approved by the Product Owner and then added to the Product Backlog.
7. Sprint Review
At the end of the Sprint, there is a Sprint Review, where the Developers demo or play done videos of the completed PBIs. The goal is for the Product Owner to understand the increment and to discuss the feedback to make the product better. This is the real measure of success of the Sprint.
8. Retrospective
Lastly, there is the Sprint Retrospective, and this is the best part! The Scrum Team discusses what went well, what didn’t, and what to improve, always inspecting and adapting.
From here, another Sprint Planning session commences, and the wheel keeps turning, getting better and better with every revolution.
Source : https://www.ssw.com.au/rules/8-steps-to-scrum/
Les rôles de Scrum
Developers : Les membres de l’équipe de développement qui sont responsables de la création du produit. Ils sont auto-organisés et interviennent dans tous les aspects du travail.
Product Owner (PO) : Membre de l’équipe (généralement le client) responsable de définir et de prioriser le travail de l’équipe de développement en fonction de ses besoins.
Scrum Master : Membre de l’équipe chargé de la bonne application de Scrum au sein de l’équipe de développement et de supprimer les obstacles qui entravent leur progression.
