1- The Development Team:
Two essential characteristics: Self-organized ; Cross-functional.
It is small enough to remain responsive and large enough to deliver a "Done" increment every Sprint (3 to 9 people with a preference for 5 to 7 people).
It might be required to have more team members for larger projects. In that case, we can use multiple teams for a single product, and it is called scaled Scrum.
Scrum does not recognize any titles within the Development Team.
2- Responsablities:
It accountable for:
- Creating a plan for the Sprint, the Sprint Backlog;
- Instilling quality by adhering to a Definition of Done;
- Adapting their plan each day toward the Sprint Goal;
- Holding each other accountable as professionals.
3- The services of the Scrum Master:
3.1- Help the team set it's own goals and they can be ambitious:
- coaching in self-management and cross-functionality
- guide towards two indicators: velocity and quality.
- put operational errors into perspective using performance growth curves: we progress more quickly following a failure than by chaining successes.
3.2- Efficiently complete the Sprint Backlog:
“The Sprint Backlog is the set of items selected for the Sprint plus a plan to deliver the product increment and achieve the Sprint goal.”
Scrum Guide 2017
The Product Backlog is made up of elements that make up the product: user stories, functions, flows, corrections ...
The Sprint Backlog is made up mostly of tasks that don't take more than a day to complete.
Several techniques allow you to build a "good" Sprint Backlog:
• Refine the Product Backlog items to a "ready" state.
• Integrate elements allowing the implementation of the improvement of at least one process identified in the previous Sprint retrospective.
• Plan the activity for the upcoming Sprint.
3.3- Focus on creating high-value Increments (product) that meet the Definition of Done:
For once, we will not rely on the Scrum guide in the first place to understand the issues and therefore consider the means to be implemented, but on a publication by Jeff Sutherland (author of Scrum) dating from 2012. This document has the merit of explaining in detail the reasons which led Ken Schwaber and Jeff Sutherland to recommend certain Scrum practices, in order to maximize the chances of being able to deliver a finished product.
“To effectively deliver a potentially deliverable product at the end of the Sprint, experience has shown that:
1. There must be a Product Owner who provides the team with a clear list of consistent, fixed priorities for the duration of a Sprint. Decades of software engineering experience have shown that giving a development team multiple priorities or changing priorities during an iteration leads to delayed decisions and excessive rework. Reducing the productivity of these teams by more than 50% is the norm. Many development teams doubled their productivity in the first month of implementing Scrum by solving this problem.
2. The Product Owner must have a scheduled Features Product Backlog ..."
3.4- Estimate the complexity:
“The elements of the Product Backlog have as attributes: a description, an order, an estimate and a value. "
Scrum Guide 2017
According to the Scrum guide, each item in the Product Backlog must have at least these four attributes, including an “estimate”. The Scrum guide specifies that:
“The development team is responsible for all estimates. The Product Owner can influence the development team by helping them understand and choose trade-offs, but the people who will do the work have the final say on the estimates. "
Scrum Guide 2017
The guide talks about estimates, clearly describing who is responsible for those estimates - the development team - but without specifying what is being estimated and how. Is this an estimate of load expressed in man-days, duration expressed in hours, an estimate of effort or complexity? Nothing indicates it, the reasons for these estimates are implicit, but are not described in an explicit way either. Finally, the means to achieve this are completely free.
The objective of these estimates is also inferred without being expressed explicitly. This should make the planning more precise.
3.6- Causing the removal of impediments progress
3.7- Ensuring that all Scrum events take place and are positive, productive, and kept within the timebox
3.8- Give visibility
Giving visibility is about increasing transparency. As a reminder :
“Important aspects of the process need to be visible to all who are responsible for the outcome. Transparency requires the definition of a common standard for these aspects, so that observers share a common understanding of what is observed ... / ...
Scrum is based on transparency. Decisions to optimize value and control risk are made based on the perceived condition of the artifacts. As long as the transparency is complete, these decisions have a solid basis. Since artefacts are not fully transparent, these decisions can be skewed, lower value and increased risk. "
Scrum Guide 2017
• Sprint burndown chart
• Release burndown chart
• Product burndown chart
