Le guide Scrum a été mis à jour pour clarifier certaines règles et éliminer les pratiques optionnelles, sans remettre en cause les principes fondamentaux de Scrum. Les changements notables incluent la définition de l'équipe de développement, la gestion de l'engagement au cours des sprints, et la flexibilité du backlog de produit. Ces ajustements visent à corriger des malentendus de longue date et à rationaliser le langage utilisé dans la communauté Scrum.

1. Traduit par Fabrice Aimetti le 9 août 2011
Mise à jour Scrum : 2011
Pour la plupart des jeux et des activités, les règles sont publiées et considérées comme à part de la stratégie.
Par exemple, les règles des échecs ne donnent aucun indice à propos des différentes stratégies qui ont pu se
développer pour jouer à ce jeu ; il en est ainsi des règles de Scrum.
Avec cette distinction à l'esprit, Jeff Sutherland et moi-même avons le
plaisir de de vous annoncer la prochaine mise à jour de Scrum via la
publication du Guide Scrum. Nous avons étroitement travaillé avec la
communauté. David Starr et Jim Coplien ont matériellement contribué à
cet effort. Nous avons par la suite l'intention de procéder à des mises à
jour annuelles.
Le Guide Scrum énonce les régles de Scrum et constitue la
documentation de Scrum lui-même. Le Guide Scrum et les règles des
échecs offrent simplement les règles de déplacement des pièces,
comment jouer à tour de rôle, ce qu'est une victoire, et ainsi de suite.
Les stratégies pour jouer à Scrum ou aux échecs varient grandement et sont respectivement expliquées dans
plusieurs livres, articles et blogs. Pour ceux d'entre nous qui ont travaillé sur la révision du Guide Scrum, cela
a signifié que toutes les astuces, pratiques optionnelles et techniques devaient être supprimées de ce
document. C'est ce que nous avons fait en précisant le langage employé pour corriger certains malentendus
de longues dates sur Scrum.
Nous souhaitons partager ici certains des changements effectués dans cette version affinée du discours
Scrum. Bien que rien dans Scrum ne soit fondamentalement remis en cause, certaines clarifications que nous
apportons ont mis du temps à venir. Chacune d'entre elles méritera probablement d'être commentée dans
un futur billet, nous allons donc simplement les recenser ici.
• L'équipe qui réalise le travail pour créer un Incrément est l'Equipe de Développement. Quel que soit
le travail réalisé par chacun des membres de l'équipe, ils sont connus sous le nom de Développeurs.
• L'Equipe de Développement ne s'engage pas à finir le travail planifié au cours de la Réunion de
Planification du Sprint. L'Equipe de Développement prévoit le travail qu'elle pense pouvoir finir,
mais cette prévision changera à mesure que l'Equipe en apprendra davantage au cours du Sprint.
• Scrum n'exige pas d'utiliser un burndown chart pour suivre l'état d'avancement. Scrum exige
seulement que :
• Le reste à faire d'un Sprint soit additionné et connu quotidiennement.
• La courbe illustrant la tendance à finir le travail du Sprint soit maintenue tout au long du Sprint.
• Le Planning de Release est intéressant lorsqu'on utilise Scrum mais n'est pas exigé par Scrum lui-
même.
• Le Backlog de Sprint est constitué des éléments du Backlog Produit sélectionnés pour le Sprint, plus
une stratégie pour les livrer. Nous n'avons plus besoin du concept d'"éléments du Backlog de
Sprint" même si cette technique pouvait nous permettre d'obtenir une bonne stratégie. Une Equipe
de Développement auto-organisée dispose toujours d'une stratégie.
• Le Backlog de Produit est "ordonné", au lieu d'être "priorisé", fournissant de la flexibilité au Product
Owner pour optimiser la valeur compte tenu de son contexte bien particulier.