Adapt or die, is an omnipresent reality in the software development world, and of course Scrum is not an exception. After more than 20 years of history, the most popular agile framework gets an update which doesn’t alter any fundamental principle, but which is good to make some clarifications needed since long time ago. And also, as my fellow/trainer at Scrum.org Giovanni Bassi states, to stress the character of Scrum as a framework more than as a methodology.
The update is reflected in the new version of the Scrum Guide, published by Scrum.org last July 15th 2011. The revision has been done by the creators of Scrum, Ken Schwaber and Jeff Sutherland, with the participation of David Starr, Jim Coplien and other contributors. The Scrum Guide itself has been deeply renovated, with the goal of making it clearer and concise, and to have it gather the Scrum rules in an univocal way. For this reason, they have been excluded from the guide all the tips, strategies, practices and techniques which, even though being useful, aren’t prescribed by Scrum, and thus are optional.
The most important modifications to Scrum, which the authors themselves have gathered in a document, are the following ones:
- The team of people who are in charge of doing the work of creating each increment, is now called Development Team. All the members are Developers, no matter the concrete work they’re doing (coding, testing, design, architecture…). This modification, although seems a simple naming change, has several advantages. First, it reduces the confusion that could exist until now, since the Development Team was called simply Team. I Scrum we deal with another team which is called the Scrum Team (composed of the Development Team, the Scrum Master and the Product Owner), so the distinction between them is clearer. Furthermore, it stresses the cross-functional character of the team as a group of developers, beyond the simple sum of people with concrete roles.
- Until now, we said that the Development Team, during the Sprint Planning Meeting, makes a commitment about the work to be completed. The term commitment has been substituted by forecast, so during the Sprint Planning Meeting, the Development Team makes a forecast about the work to be completed during the Sprint. Once again, it may seem a simple naming change, but in my opinion, it has a good purpose: when doing a commitment, we’re ignoring the uncertainty which is present in any Sprint, pretending that we’ll complete the committed work even though changes or difficulties get in the way. Forecast is a more adequate word in order to state that we’ll try to complete the work, but that the result at the end of the Sprint can be different. Does this mean that Developers are now less responsible for their work, or that they can relax during it? That’s not the case: Development Team keeps on committing, of course. But commitment to a concrete list of items is something that usually doesn’t get well with uncertainty and with what happens in reality, while there’s more value in committing to things like working with professionalism, making things the better you can or even fulfilling the Sprint Goal – which gives us guidance about the scope of each Sprint.
- Burndown charts (Relase Burndown, Product Burndown, Sprint Burndown), are no longer mandatory in Scrum. We’re supposed to keep on measuring remaining work each day of the Sprint, and the trend towards the end. But the specific tool to use, is up to ourselves. Of course, burndown charts are still an excellent option, though we can use any other progress tracking tool: other kinds of graphs, simple numeric values, percentages, subjective measurements or whatever better fits our needs.
- Scrum no longer addresses the concept of Release Planning. It’s something that undoubtedly can be valuable in many organizations and development efforts, and in these cases we’ll obtain benefit from keeping on doing it. But if the circumstances of our organization or development don’t require it, or if we don’t need to keep a medium/long term vision about what we want to achieve, we can simply get to work without worrying about the planning further than the next Sprint horizon. This nuance promotes the framework character of Scrum, and makes it easier to apply it to many development efforts where the short term vision is much more important than having a very clear understanding about where are we going to.
- It is no longer mandatory to maintain a bunch of Sprint Backlog Items for each Sprint. Until now, the Sprint Backlog was the list of tasks and concrete pieces of work, resulting of decomposing and analyzing the (commited) forecasted Product Backlog Items for each Sprint. From now on, the Sprint Backlog is simply the forecasted Product Backlog Items, plus a plan to complete them. The concrete definition of what a plan consists on, is left up to the Development Team; of course, we can keep on using a tasks list to reflect the plan, but we have the possibility to choose another options. Many times it’s difficult to decompose into tasks a particular PBI, or it’s not worth the effort, or other mechanisms are preferred in order to express how are we going to do the work. The new version of Scrum gives us the chance of using tasks, or substitute them by any other mechanism, be it a high-level description, a further elaborated technical design (have in mind the exhaustive documentation issue…), or any other option that better fits our needs. Once again, this update stresses the framework nature of Scrum over being a methodology.
- The Product Backlog has to be ordered, instead of having to be prioritized. It is, once again, a naming change which maybe will be not so important for many people, and in the other hand will bring difficulties to others, but as the former ones, it has a purpose. In fact, prioritization is nothing but a particular kind of ordering based in relative importance or ROI, but usually these parameters are not the only ones to have in mind when finding out the optimum order in which things should be delivered. I’ll try to clarify furthermore this point in some future post or reference, as well.
Besides from the enumerated changes above, which are the ones stressed by the authors themselves, the new version of Scrum brings some additional changes which I think worth mentioning:
- The minimum recommended number of people for a Development Team is now 3, instead of 5 as it used to be. Nevertheless, the Guide puts clear that the limits are only a guideline, and that the optimum size of the Development Team is the minimum needed to complete the work, and the maximum required to keep agile.
- There are other minor naming changes; for example, it’s again being used Scrum Master instead of ScrumMaster, or the term Timebox is replaced by Event when referring to the several meetings in a generic way.
- The role and responsibilities of the Product Owner are much more clear and defined than in former versions of the Guide.
I believe that the Scrum update is a very nice piece of news, because it demonstrates the concern of the authors about keeping it up to date and make it more flexible, in order to deal with the changing needs of developments.
Below you can see myself and other fellow trainers from Scrum.org with Ken Schwaber and David Starr, during the last meeting at Boston where we discussed about these and many other interesting subjects .