We used to work in watterfall way in the software industry development. We started from a need then we analysed them, write a road map, write code and then the project was finished. The problem was that the final product didn’t satisfy the final user. The difficulty was to know exactly what we need at the begining. Needs can changed
Then come Agile methodes with 4 values
- Individuals and interactions over processes and tools
- Working software over comprehensive documentation
- Customer collaboration over contract negotiation
- Responding to change over following a plan
This idea is to be focus on the product and to get feedback frequently . The other idea is to have a self organised teamé.
What is SCRUM
Scrum is a framework for developing, delivering, and sustaining complex products.
Scrum is: Lightweight, Simple to understand , Difficult to master
Scrum is not a process, technique, or definitive method. The Scrum
framework consists of Scrum Teams and their associated roles, events,
artifacts, and rules.
Scrum is based on empirism that asserts that knowledge comes from experience and making decisions based on what is known. Scrum employs an iterative, incremental approach
SCRIM is 3 pillars, 5 values, 3 roles, 3 events and 3 artifacts.
- Transparency: must be visible to those responsible for the outcome. Nothing is hiddent. Observers share a common understanding of what is beeing see. Those performing the work and those inspecting the result must share a common definition of done.
- Inspection: Scrum users must frequently inspect Scrum artifacts and progress toward a Sprint Goal to detect undesirable variances
- Adaptation: Events of scrum are occasion for inspection and adaptation.
- Commitment : .People personally commit to achieving the goals of the Scrum Team
- Courage: Scrum Team members have courage to do the right thing and work on tough problems.
- Focus: Everyone focuses on the work of the Sprint and the goals of the Scrum Team.
- Openness: The Scrum Team and its stakeholders agree to be open about all the work and the challenges with performing the work.
- Respect : Scrum Team members respect each other to be capable, independent people.
The Scrum Team is the Product Owner, the Development Team and a Scrum Master. Scrum Teams are self-organizing and cross-functional. Self-organizing teams choose how best to accomplish their work, rather than being directed by others outside the team. Cross-functional teams have all competencies needed to accomplish the work without depending on others not part of the team
The Product Owner is responsible for maximizing the value of the product
resulting from work of the Development Team. The Product Owner is one
person, not a committee
- Clearly expressing Product Backlog items
- Ordering the items in the Product Backlog to best achieve goals and missions
- Optimizing the value of the work the Development Team performs
- Ensuring that the Product Backlog is
visible, transparent, and clear to all, and shows what the Scrum Team
will work on next; and,
- Ensuring the Development Team understands items in the Product Backlog to the level needed.
The Development Team do the work of delivering a potentialy releasable
increment of Done product at the end of each Sprint. The team organize
and manage their own work.
The size of the Development Team is from 3 to 9.
Monitoring Sprint Progress :
It is responsible for tracking the total work remaining at least for
every daily scrum to project the likelihood of achieving the sprint
goal. It manage its progress
The Scrum Master
Scrum Master Serves to the Product Owner He ensure that goals, scope and product domain are understood by everyone. He helps him in finding techniques for effective Product Backlog management. Ensure that he knows how to arrange the Product Backlog to maximize value. And he facilitate scrum events.
Scrum Master serves the Organization
- Leading and coaching the organisation
- Planning Scrum implementations within the organization;
- Helping employees and stakeholders understand and enact Scrum and empirical product development;
- Causing change that increases the productivity of the Scrum Team
- Working with other Scrum Masters to increase the effectiveness of the application of Scrum in the organization
Scrum organise event in order to minimize the need for other meetings. All events are time boxed with a maximum time of duration
The Sprint is the heart of Scrum. Sprints contain and consist of the
Sprint Planning, Daily Scrums, the development work, the Sprint Review,
and the Sprint Retrospective.
During the Sprint: No changes are made that would endanger the Sprint
Goal, Quality goals do not decrease and Scope may be clarified and
re-negotiated between the Product Owner and Development Team as more is
The Sprint planning
This work is done with the Scrum Team. Duration maximum 8 hours for a sprint of one month.
Durée maximum 8 heures
Le Scrum Master veille à ce que l’événement ait lieu et que tous en
comprennent le but. Il fait attention à sa durée. Il y a deux parties
dans cette planification
Topic One: What can be done this Sprint?
The Development Team works to forecast the functionality that will be developed during the Sprint. The Product Owner discusses the objective that the Sprint should achieve and the Product Backlog items that, if completed in the Sprint, would achieve the Sprint Goal. The entire Scrum Team collaborates on understanding the work of the Sprint. During Sprint Planning the Scrum Team also crafts a Sprint Goal.
Topic Two: how will the chosen work get done?
The Product Backlog items selected for this Sprint plus the plan for delivering them is called the Sprint Backlog.
Product Owner help Le Product Owner aide à la clarification du Backlog Product. Il y a négociation avec l’équipe de développement lui si il y a trop ou pas assez de travail.
The Product Owner can help to clarify the selected Product Backlog items and make trade-offs.
If the Development Team determines it has too much or too little work, it may renegotiate the
selected Product Backlog items with the Product Owner. The Development Team may also invite
other people to attend to provide technical or domain advice.
By the end of the Sprint Planning, the Development Team should be able to explain to the
Product Owner and Scrum Master how it intends to work as a self-organizing team to
accomplish the Sprint Goal and create the anticipated Increment.
The Sprint Goal provides guidance to the Development Team on why it is building the Increment. It is created during the Sprint Planning meeting.
Every day at the same hour and place the development team meet together for 15 mn maximun. Each member explain to the Team what they did yesterday, what they are doing to do today and if they see impediment.
A Sprint Review is held at the end of the Sprint to inspect the Increment and adapt the Product Backlog if needed.The Product Owner explains what Product Backlog items have been “Done” and what has not been “Done”. The Development Team discusses what went well during the Sprint, what problems it ran into, and how those problems were solved. Stakeholder can share feedback.
The Sprint Retrospective
The purpose of the Sprint Retrospective is to:
- Inspect how the last Sprint went with regards to people, relationships, process, and tools;
- Identify and order the major items that went well and potential improvements; and,
- Create a plan for implementing improvements to the way the Scrum Team does its work.
Scrum’s artifacts represent work or value to provide transparency and opportunities for inspection and adaptation. Artifacts defined by Scrum are specifically designed to maximize transparency of key information so that everybody has the same understanding of the artifact.
The Product Backlog is an ordered list of everything that is known to be needed in the product. It is the single source of requirements for any changes to be made to the product. The Product Owner is responsible for the Product Backlog, including its content, availability, and ordering.
Items : description, order, estimation and value.
Many Scrum Team can work and the same Product Backlog.
Product Backlog Raffinement is the act of adding detail, estimates, and order to items in the Product Backlog. This is an ongoing process in which the Product Owner and the Development Team collaborate on the details of Product Backlog items. During Product Backlog refinement, items are reviewed and revised. The Scrum Team decides how and when refinement is done. Refinement usually consumes no more than 10% of the capacity of the Development Team. However, Product Backlog items can be updated at any time by the Product Owner or at the Product Owner’s discretion.
The Sprint Backlog is the set of Product Backlog items selected for the Sprint, plus a plan for delivering the product Increment and realizing the Sprint Goal. The Sprint Backlog is a forecast by the Development Team about what functionality will be in the next Increment and the work needed to deliver that functionality into a “Done” Increment.
The Increment is the sum of all the Product Backlog items completed during a Sprint and the value of the increments of all previous Sprints. At the end of a Sprint, the new Increment must be “Done,” which means it must be in useable condition and meet the Scrum Team’s definition of “Done”. An increment is a body of inspectable, done work that supports empiricism at the end of the Sprint. The increment is a step toward a vision or goal. The increment must be in useable condition regardless of whether the Product Owner decides to release it.
Definition of Done
Cette définition doit être la même pour tout le monde à l’intérieure d’une équipe Scrum. Cette définition peut évoluer et être plus juste au fur et à mesure des Sprints.
When a Product Backlog item or an Increment is described as “Done”,
everyone must understand what “Done” means. Although this may vary
significantly per Scrum Team,
members must have a shared understanding of what it means
for work to be complete, to ensure transparency. This is the definition
of “Done” for the Scrum Team and
is used to assess when work is complete on the product
The same definition guides the Development Team in knowing
how many Product Backlog items it can select during a Sprint Planning.
The purpose of each Sprint is to
deliver Increments of potentially releasable functionality
that adhere to the Scrum Team’s current definition of “Done”.