PM 2 go Standards

Projektmanagement wird ein zunehmend wichtigerer Erfolgsfaktor fr Unternehmen im Wettbewerb. In dieser Ausgabe von PM 2 go Standards lesen Sie die Kurzartikel rund um Standards aus dem Blog Unlocking Potential von Projekt Management Beratung.

Deep-diving into the new Scrum Guide the new roles

By Andreas Heilwagen on August 1st, 2011

Deep-diving into the new Scrum Guide the new events

By Andreas Heilwagen on August 1st, 2011

As discussed yesterday, the Scrum Guide 2011 brings updated roles. Besides that, the events have changed too:

While reading the 2010 and 2011 Scrum Guides side-by-side, I got a deeper understanding of the update. While the Scrum Guide has been stripped of some best practices to contain only the core, the language and structure have improved a lot. The new guide ends with the clear rule, that you do Scrum if you implement at least the framework described in the guide, otherwise you do something, but not Scrum. To get the removed back practices back to the light, a Best Practice Compendium is planned by the authors. Now lets have a look at the changes in more depth.

Sprints
A new requirement is, that Sprints have the same length throughout the development of a product. In my opinion, Sprint lengths may vary if there are good reasons, but the Sprint length should be kept the same if possible. While the Sprint length is now fixed, the scope is not as written down in the old Scrum Guide ([] team commits to doing a PBI in the sprint []). The Development Team now does its best to create a forecast of what it can achieve during a Sprint. If necessary, the scope can be renegotiated while the Development Team learns more during the Sprint as long as the Sprint Goal is still valid.

Product Owner
The rules in Scrum have been defined more clearly and new responsibilities have been added. E.g. the Product Owner is not only responsible for the value of the Product Backlog Items, implemented in a Sprint. He is now also responsible for ensuring the value of the work the Development Team performs and that the Product Backlog is visible, transparent, and clear to all. While adding slightly more responsibilities, that borders between Product Owner and Development Team have been blurred as the Product Owner can now have the Development Team do some of his tasks. He remains accountable for the delegated work in any case.

Daily Scrum
There is a now goal for the Daily Scrum now: create a plan for the next 24 hours. The exchange of information between the Development Team members is still there, but it is more important to assess progress towards the Sprint Goal and to formulate how to reach it each day.

Development Team
Form my perspective, a major change is the reduction of the minimum recommended Development Team size from 5 to 3 team members. The old rule was 7 +/-2, the new one is 3 up to 9 team members. If a small team is the right choice depends on the scope of a Sprint as the Development Team has to able to turn all Product Backlog Items into Done Increments without delying on dependencies.

Sprint Backlog
Again, the Sprint Backlog does not contain Technical Tasks anymore. It contains Product Backlog Items (PBIs) which denote the plan to deliver the product increment and realizing the Sprint Goal. New PBIs are added by the Development Team during the Sprint as more is learned. During the Sprint Planning, PBIs from the Product Backlog are moved to the Sprint Backlog, so they are estimated. The Scrum Guide does not requires estimates for PBIs added to the Sprint Backlog, although it is implicitely required to estimate the remaining work. How that is done is up to each organization.

Scrum Master
The role of the Scrum Master as servant-leader has been defined more precise based on his services to the other Scrum Team members. The following updates make the role a lot clearer: Service to the Product Owner
o

Finding techniques for effective Product Backlog management Clearly communicating vision, goals, and Product Backlog items to the Development Team In the past, this has been the responsibility of the Product Owner and I would prefer that there would be no change. Otherwise the Product Owner and the Scrum Master can debate whose fault it was, why communication did not work out. Teaching the Development Team to create clear and concise Product Backlog items This is new, as there are no Technical Tasks required anymore. The Development Team adds, updates and removes Product Backlog Item in/from the Sprint Backlog, containing all Product Backlog Items which are planned for implementation in a Sprint. Leading and coaching the organization in its Scrum adoption

Sprint Burndown Chart

Not only the Sprint Burndown Chart has been removed from the Scrum Guide, the time spent is also not relevant anymore, only the remaining work is important. Another paragraph in the guide still notes that historical information is helpful, but important lessons from project management have been forgotton. Metrics and historical information is the basis for continuous improvement and so a history of the velocity is very important. During the next weeks, Ken Schwaber and Jeff Sutherland plan to shed more light on the updates in the Scrum Guide, so stay tuned.

Service to the Organization

o

The scope has been extended and is no longer limited to the Scrum Team but encompasses all necessary organizational units.
o

Working with other Scrum Masters to increase the effectiveness of the application of Scrum

New concepts
Besides Development Team and Forecast covered in my last post, the Scrum Meetings and the Sprints are now called Scrum Events. For the first time, the term Project can be found in the Scrum Guide, although the connection between a Sprint and a 1-monthproject is questionable. Stay tuned for part 2 of this posting tomorrow