The new Version of the Scrum Guide

The new version of the Scrum Guide written by Ken Schwaber and Jeff Sutherland is available since July 2011. The older version was published in May 2009. I found quite interesting the precisions about the Scrum Master responsibility. I have often discussions with the customers and companies I coach about the responsibility of the Scrum Master.

• Who is responsible for the introduction of the Scrum approach in the company? Often people state that the management should spread Scrum in the company. Ken and Jeff have a clear idea who is in charge of this.
  
  
  The Scrum Master serves the organization in several ways, including:
  

  • Leading and coaching the organization in its Scrum adoption;
  • 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; and,
  • Working with other Scrum Masters to increase the effectiveness of the application of Scrum in the organization.
  
  So the Scrum Master is a main driver for the introduction of Scrum in all departments and levels in the company. He needs indeed senior management support but the Scrum Master daily job is to spread Scrum in the company.
• Who should coach the product owner to write better backlog and clarify the vision?
  
  
  The Scrum Master serves the Product Owner in several ways, including:
  

  • Finding techniques for effective Product Backlog management;
  • Clearly communicating vision, goals, and Product Backlog items to the Development Team;
  • Teaching the Development Team to create clear and concise Product Backlog items;
  • Understanding long-term product planning in an empirical environment;
  • Understanding and practicing agility; and,
  • Facilitating Scrum events as requested or needed.
  
  So the Scrum Master should also coach the product owner and support him in the long term planning, the communication of the vision and backlog management. The vision and goals of the project should always contain an overall planning frame. During the project empirical evidence will trigger revision of the milestones and product planning.
• What is the meaning of done and a piece of potentially shippable product?
  
  
  When the Product Backlog item or an Increment is described as “Done”, everyone must understand what “Done” means. Although this varies 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 Increment.

Development Teams deliver an Increment of product functionality every Sprint. This Increment is useable, so a Product Owner may choose to immediately release it. Each Increment is additive to all prior Increments and thoroughly tested, ensuring that all Increments work together.

As Scrum Teams mature, it is expected that their Definition of “Done” will expand to include more stringent criteria for higher quality.
  
  
  The Increment is the sum of all the Product Backlog items completed during a Sprint and 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”.

It must be in useable condition regardless of whether the Product Owner decides to actually release it.
  
  So at the end of sprint all stories realized since the start of the project must be correct. Therefore you need automated acceptance tests to guaranty their correctness. The Scrum team must guaranty that at the end of each sprint all functions of the product work as specified and accepted by the product owner in the current and previous sprint reviews.
  
  Higher quality is reached through extreme programming approach: test driven development, clean code, pair programming, pair check-in, coding dojo, static analysis tools.
• Does Scrum consider long-term planning?
  
  Yes it is a major activity performed by the Scrum Master and Product Owner. See the above point about the Scrum Master coaching the Product Owner. See if anyone states that long-term planning is not part of the Scrum theory you should challenge them and give them the Scrum Guide to read.
• What can be changed during a Sprint? Often customers have heated discussions what can be changed during a sprint. Here a clear statement.
  
  
  During the Sprint:
  

  • No changes are made that would affect the Sprint Goal;
  • Development Team composition and quality goals remain constant; and,
  • Scope may be clarified and re-negotiated between the Product Owner and Development Team as more is learned.
• What is measured in a burn down chart?
  
  
  Scrum does not consider the time spent working on Sprint Backlog Items. The work remaining and date are the only variables of interest.
  
  The only relevant information is the amount of work still open and when this work will be completed. This is true for sprint, release and whole backlog burn-down chart.

I am glad that these precisions were added to the new version of the Scrum guide. I simplify my daily work. I can now simply refer the official Scrum Guide to convince people how aspects of Scrum should be understood.
The older version of the Scrum Guide is still relevant because it contains hints and best practices no more part of the new version.