The Version of the Scrum Guide 2011
The new version of the Scrum Guide written by Ken Schwaber and Jeff Sutherland has been available since July 2011.
You should regularly read the Scrum guide to reflect how your teams are applying agile principles and ideas.
You should also consult the seminal Agile Manifesto and the 12 Agile Manifesto Principles.
The older version was published in May 2009.
I found quite interesting the precision of the Scrum Master’s responsibility.
I have discussions with the customers and companies I coach about the responsibility of the Scrum Master.
Below key statements I find useful for Scrum masters and agile enthusiasts.
Who is responsible for the introduction of Scrum?
People often state that 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 how Scrum is applied in the organization.
The Scrum Master is a main driver for the introduction of Scrum in all departments and levels in the company. He needs senior management support, but the Scrum Master daily job is to spread Scrum in the company.
Who should coach the product owner?
The Scrum Master serves the Product Owner in several ways, including:
Finding techniques for effective Product Backlog management.
Communicating vision, goals, and Product Backlog items clearly 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.
Facilitating Scrum events as requested or needed.
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 product should always contain an overall planning frame. During product development, empirical evidence will trigger revision of the milestones and product planning.
What is a 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 a working product, 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 usable condition and meet the Scrum Team’s Definition of Done.
It must be in usable condition regardless of whether the Product Owner decides to actually release it.
So at the end of the sprint, all stories realized since the start of the product 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 an 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 that 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 the 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 to 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.