The Evolution of The Scrum Guide (Part One)

  • 27 Jun, 2014

How the unofficial 'Book of Knowledge' has changed

You may not have noticed, but in July 2013 Jeff Sutherland and Ken Schwaber published a new version of  The Scrum Guide: The Definitive Guide to Scrum: The Rules of the Game . Don’t worry if you were unaware of this, the update was not accompanied by fanfare and so you are not alone. But as  The Scrum Guide  is referred to by many – myself included – as the ‘book of knowledge’ of Scrum I thought I might devote some effort in tracing the most recent changes as well as its overall evolution.

The current version of  The Scrum Guide  is the third since its original publication by in February 2010 (although the original paper did not formally use the title -it was simply called  Scrum  – it was generally referred to by the name it acquired in the subsequent versions). The second edition appeared in October 2011, and it is this version that has just been updated. The changes between the first and second version were more obvious and perhaps more profound than those between the current edit and its predecessor but, of course, in its essentials Scrum is unchanged. In all three editions it is stressed that Scrum is a  framework  of roles, artifacts and events bound together by rules which is used for building and sustaining complex products. There is no such thing as the Scrum  process . The framework’s role is “to surface the relative efficacy of your development practices so that you can improve upon them”. Rooted as it is in empirical process control theory, we can interpret it to say that the ‘process’ that Scrum drives out is the sum total of all the decisions that the Scrum Team(s) take to remove impediments and improve their work. The resulting process will, therefore, be different from product to product, from context to context, even for different applications of the framework in the same organization.

The fundamental idea of Scrum as a framework rather than a method or a defined process is what  The Scrum Guide  distilled in 2010, clearing up confusions and misconceptions which had gathered around it since its first public presentation to the software engineering community in 1995. Since then, changes to  The Scrum Guide can be considered to be driven by three forces: first, a desire to strip the framework down to its bare essentials in order to define what any project (irrespective of size or context) must be doing for it to legitimately claim to be using Scrum; second, the incorporation of industry experience of using the framework; and thirdly the desire to remove ambiguities by clarifying the language.

Roles, Events and Artifacts

One of the biggest changes between the first two editions of the guide was in its description of the roles, events and artifacts of Scrum. I am not referring to mere cosmetics here: The “Team” became the “Development Team”, “timeboxes” became “events” and the spelling of “ScrumMaster” changed to “Scrum Master”, for example. Much more importantly, the original spoke of three checkpoints for inspection and adaptation( folding the Sprint Review and Sprint Planning Meeting together as instruments for inspecting “progress towards the Release Goal”), and of four “principal” artifacts that were the Product Backlog, the Sprint Backlog, the Sprint Burndown and the Release Burndown. The Release Planning Meeting was included as an optional timebox – in fact the only optional timebox alongside the mandatory Sprint Planning Meeting, Daily Scrum, Sprint Review and Sprint Retrospective.

These days I talk of Scrum consisting of the 3-4-5 ‘rule’: three roles (Product Owner, Scrum Master and Development Team), four artifacts (Product Backlog, Sprint Backlog, Definition of Done and the end-of-Sprint Increment) and five events (Sprint, Sprint Planning Meeting, Daily Scrum, Sprint Review and Sprint Retrospective) and that’s been consistent with what the Guide has said since October 2011. But you’ll notice that there is no reference in this to either a Release Goal or a Release Planning Meeting and that while the Sprint and Release Burndowns have been dropped, the Definition of Done and the Increment have been elevated to replace them in the list of artifacts. This is also consistent with the later versions of The Scrum Guide in which there is no mention of “Release Planning Meeting”, “Release Goal” or of “Burndown” of any description.

So how should we understand these changes? The most important thing to understand is that Sutherland and Schwaber are by no means deprecating release goals, release planning and Burndown or implying in any way that practitioners of Scrum should not be doing them. I reckon that maybe 9 out of 10 Scrum Teams use Burndown charts, and almost any medium to large size product lifecycle probably needs release planning meetings. The point is they are not  universally  required. It is entirely possible for a Team to do all the stuff that would otherwise take place in a release planning meeting in the Sprint Planning meetings if, for example, the overall work was of an appropriate size and, equally, a Scrum Team might choose ways to make the progress of a Sprint (or a Release) visible other than by showing it in Burndown charts. Remember, the Release Planning Meeting was described originally as optional, in any case. No, the point is that because you can still be using the Scrum Framework without doing these things they have been removed from the Guide. Everything that remains is mandatory.

Along the same lines we might note that the 2010 paper included fifteen tips, or tactics, that are not part of the Scrum Framework  per se  but were included as helpful suggestions. One of those, incidentally, referred to Product Backlog items as being “usually stated as User Stories”. This is the only reference to stories anywhere in the history of the Guide but, like all the tips, it has been removed because the use of stories is not mandated although widely used by Scrum teams. I guess the authors’ feeling was that by including the tips they somehow de-emphasized the important idea that for most issues “the users of Scrum are expected to figure out what to do.”

The Definition of Done

If all mention of Release Planning and Release Goals together with Burndown was dropped from the revision in October 2010, then the importance of the Definition of Done and the Increment of functionality were promoted. Don’t get me wrong here, there was considerable discussion of both in the original paper but it was given new prominence by including each of them in the list of artifacts from the second version onwards.

In my own experience, the emphasis that Scrum gives to presenting a slice of functionality which is “potentially releasable” and the stress it places on quality is often missed by organizations who think they are implementing the framework. To be honest, due emphasis has often not been given by people who purport to be training developers in the use of Scrum. Perhaps similar observations lay behind the Guide’s authors’ choice to reframe the material around these two topics.

Even the first paper stated very clearly that all Sprints deliver an increment of the final product that is potentially releasable, and that it was the (Development) Team’s job to turn Product Backlog items into such increments in every Sprint. “More and more Sprints create additional increments” until there is sufficient value accumulated for the product to be released. There is a strong implication in the original, but only made explicit from the 2011 version onwards, that the decision about what and when to release is one made by the Product Owner.

This is, of course, what makes Scrum difficult to apply, especially at first. Not only is a slice of functionality mandated to be delivered at the end of every Sprint, but it is required that the product be “potentially shippable”, i.e., it must meet the quality standards of shippable product even if it is not going to be released yet: it must be ‘done’. The Definition of ‘Done’ is the Scrum Team’s shared understanding of what it means for work to be complete. It is essential to Transparency that such a shared understanding be in place. All of this was stated in the original document and has been maintained by the successive revisions.

There have been changes, however. The first version listed the types of things that would need to have been finished for a completely “done” increment: analysis, design, refactoring, documentation and testing that included unit, system, user and regression tests as well as non-functional requirements testing performance, stability, security, and integration. Internationalization is also included. All of this detail was been removed from the 2011 Guide. Clearly, it is context-specific so that change is perfectly in line with the general line of march of the framework’s evolution. As the 2013 version states “…this [i.e., the Definition of Done – AOC] varies significantly per Scrum Team” and later “Any one product or system should have a definition of “Done” that is standard for any work done on it.”

A more significant change, perhaps, between 2010 and 2011 was the removal of discussion of “Undone work”. In the section on “Done” the original Guide says that some Development Teams will not yet be able to put everything required for implementation and release into their Definition of Done, and must make that clear to the Product Owner. The remaining work would still need to be finished before the increment could actually be released, it pointed out. In other words there would be a level of doneness which would have to be achieved for anything that would be demonstrated at the Sprint Review, and another, higher level of doneness that would be needed to be reached before the product could be used by the customer. At least, that’s how I have always interpreted this section.

The work needed to bridge the gap between the two levels was called, in a Tip on the same page, “Undone work”, and the Tip implied that this should be accumulated in a Product Backlog item (PBI) and its effort estimated in the same way as the regular PBIs. The section on “Done” was immediately followed by another section called “Final Thoughts” which was completely devoted to how a Development Team might handle “undone work”. It recommended creating two explicit categories of work: one for “done” work and the other for “undone work”. The first category included the work governed by standards for the Sprint, the second category listed the work to be done at a later date. The Guide recommended that special Release Sprints be added to any release to complete the “undone work” and pointed out that the number of Sprints would be unpredictable to the degree that the accumulation of “undone work” was not linear.

All of that was removed from the Guide in the October 2011 revision and is absent from the current version, too. Again, the tactics listed were probably considered to be too specific to be truly universal (certainly, there are other ways of hardening releases other than adding Release Sprints at the end of the regular development Sprint cycle). It is definitely still the case that there are many Scrum Teams, perhaps a majority in some industry sectors, which are not in a position to put, at the end of every Sprint, slices of functionality that are genuinely potentially shippable at the disposal of the Product Owner. My own practice in these circumstances broadly follows the approach described in the original Guide, and I’m sure that’s true for a great many Scrum practitioners. The 2011 and 2013 versions of  The Scrum Guide  point out that, as Scrum Team’s mature, their Definition of Done will be expected to expand to include more stringent criteria for quality. The newest edition has added that if “done” for an increment is part of the standards, guidelines and conventions of the development organization, then all Scrum Teams must follow it as a minimum. If it is not part of an existing development standard the Development Team must define one appropriate for the product, and if there is a multiple team development for a product or a system then all the Scrum Teams working on it must mutually agree the Definition of Done.

By A O'CALLAGHAN 13 Nov, 2017

How can you assess the progress of your Agility in your organization?

Agile has apparently ‘crossed the chasm’. Its early adopters have achieved sufficient momentum to ensure its entry into the mainstream of software and IT development, if not product development in general. In fact, one estimate is that currently between 12 and 15 million people use Scrum daily. And yet a keynote speaker at the recent Global Scrum Gathering in Dublin claimed that Agile is failing, providing as supporting evidence a straw poll of attendees that showed only a small minority thought they were reaping the full benefits of agility.

I have no issue with the idea that many organizations who have adopted agile are disappointed with the results so far. We’ll come back to that a little later. But the statement that Agile has failed begs two questions. First, who put a time limit on Agile’s pathway? Secondly, and much more importantly, what is meant by ‘the full benefits’?

Agility Fluency v ‘Maturity’ Models

My point is that Agile is not an end in itself, but a means to an end: the more effective delivery of business outcomes. And these goals are highly situational. They vary from organization to organization, and even between different departments in the same organization. The ‘full benefit’ is not some absolute standard that everyone should aspire to, but something that is completely qualified by the business goals that are being set for Agile teams.

The question ‘”How Agile are we?’” is the wrong question. It raised the spectre of ‘maturity’ models that really are ghosts that should have been banished a long time ago. Instead of Agile ‘maturity’, we should be thinking in terms of Agile fluency. Fluency is what your teams do when under pressure – the ‘muscle memory’ with which they react instinctively, without too much thinking. And the kind of fluency your teams should aspire to is determined by the goals of the organization.

An analogy might help here. I’m learning French. I need to be fluent enough to be able to converse and socialize with my neighbours in Nouvelle Aquitaine where I have a home. That is a completely different type of fluency from what someone would need for a weekend trip to Paris. Yet another kind of fluency would be needed for someone wanting to, say, teach a technical training course to French-speaking students.

James Shore and Diana Larsen’s Agile FluencyTM Model is a simple but powerful tool that helps organizations identify what kind of fluency their Agile teams need. There are four fluency ‘zones’ in the model: Focus on Value ; Deliver Value ; Optimize Value ; and Optimize Systems . At the risk of mixing metaphors, we can think of choosing a zone like we are buying a ticket on a city bus. Depending on where you want to get to, you buy a more or less expensive ticket to the zone that includes your end destination. Different types of Agile Fluency imply different levels of investment (training, coaching, tools etc.) and different benefits. The model gives you guidance in making these cost/benefit tradeoffs in your Agile investment plan.

Agile FluencyTM Diagnostics

The model is supported by the Agile FluencyTM Diagnostic tools. A trained facilitator works with management to understand its goals, and what achieving them would look like. These are then mapped to the appropriate fluency zone. The facilitator runs workshops with each of the Agile teams, collates the results and feeds back the curated, and anonymized, results to management, making recommendations for an investment plan. The idea is to provide a mirror for the teams to reflect on their progress, and identify the top two or three things that management can do to help them. These guided self-assessments can be repeated on a quarterly or six-monthly basis as part of an overall continuous improvement effort.

To sum up. Agile development is a means for the effective delivery of business value. Its progress can only be measured against the business goals it is being employed to achieve. For organizations feeling disappointed about what Agile has delivered for them this far, the way forward is to invest in the growth of their Agile teams. The Agile FluencyTM Model is just one tool, but a very useful one, that can be used to identify what kind of investment is needed, and what kinds of benefit to expect as a result.

By A O'CALLAGHAN 06 Jun, 2017

The eleventh  State of Agile survey  has just been published by VersionOne. These reports are invaluable in helping agile practitioners understand where their practices, problems and challenges fit the context of the wider world.

As with all VersionOne’s previous reports, the eleventh survey paints a picture of the onward march of agile. Its progress is rarely in a straight line, however, and this latest survey has revealed a very interesting contradiction.

Increased Focus on Business Value?

When respondents were asked how the success of agile initiatives were measured, the second ranked answer after “on-time delivery” was “business value.” In the previous report, “business value” was the fourth-ranked answer. This time, some 46 percent of respondents chose it ahead of “customer/user satisfaction” (44 percent), “product quality” (42percent) and “product scope” (40 percent). No other answer was given by more than a quarter of respondents.

By A O'CALLAGHAN 25 Apr, 2017

The definition of done (DoD) is one of the most important and least-understood elements of the Scrum Framework. It is specifically called out in “ The Scrum Guide ” in what is probably its biggest section, and yet, I’ve seen so-called ‘definitions’ of Scrum that fail to mention it at all.

In this post, we’ll be talking about why, exactly, the DoD is so important.

DoD Explained

So, what is the definition of done? Fundamentally, it is the Scrum team’s agreement about the standard of quality that it will apply across the product. This concept is closely related to that of the Potentially Shippable Increment that must be created at the end of each and every sprint. The two words in that phrase that the DoD concerns are “potentially” and “increment."

While all agile approaches – Scrum included – aspire to “deliver early and deliver often,” this does not mean that a product must be handed over to the customer at the end of every sprint. Whether enough  useful  value has been accumulated to warrant a product’s release is a business decision, and one that is the product owner’s responsibility to make. 


By A O'CALLAGHAN 24 Mar, 2017

Governance seems to be one of those frightening words that threatens to stop an Agile transformation effort dead in its tracks. I’ve been hearing it whispered, and even screamed once or twice, quite a lot recently. There’s no big surprise here. As the big corporations and Government agencies get increasingly fascinated by frameworks like Scrum, they are mandating their IT departments to “Go agile” and then, sooner or later…governance!

Types of Governance

There is operational governance represented in the defined processes that organizations and teams are expected to follow when software is in production. There is project management governance, perhaps dictated by PRINCE2 or similar, while the product is in development. PRINCE, by the way, is an acronym standing for ‘PRojects In a Controlled Environment’.

Project management governance is often a subset of a wider IT governance. According to the TOGAF version 9.1 , IT governance supposedly provides the framework and structure that links IT resources and information to enterprise goals and strategies. “IT governance institutionalizes best practices for planning, acquiring, implementing and monitoring IT performance…” Standards like COBIT, which stands for Control OBjectives for Information and related Technology, might be in place. And then, of course, there is a range of issues to do with compliance to the requirements of external regulators in all public bodies, as well as commercial institutions in sectors such as insurance and banking. So, is this a case of an irresistible force (Agile) meeting an unmovable object (governance)?

Published on 23/3/17 on Learning Tree page. 


By A O'CALLAGHAN 20 Mar, 2017

“We need to get better at estimating,” an experienced member of a Scrum development team once told me. “Management is getting concerned that we keep coming up short on our commitment.”

“Really?” I responded. “What have you been committing to?”

“Thirty story points” she said. “We get there about 50% of the time. In a couple of recent sprints, we’ve even exceeded thirty points, but the last sprint marked the third time this quarter that we fell short of our target.”

“Why was your forecast off target, do you think?” I asked.

“Well, things come out of left field occasionally. You know, stuff that couldn’t be anticipated in sprint planning,” she answered.

“So, why are you estimating effort if you can’t predict what will happen in the sprint?” I said.

Now, at this point I want to make clear that I am not one of those who say that development teams should not estimate effort. For me, the ability to estimate independently is an important part of the autonomy of teams. What I was trying to do in this particular conversation was to get the team member to consider why teams estimate in the first place, and what “commitment” means in that context.

It is not just a matter of those doing the work being the only ones who are able to estimate effort, which I believe to be true. I recently participated in a large multi-team project of effort being estimated by a centralized systems analysis unit. In that project, the development teams were involved in estimating, but it was the systems analysts’ forecast that was being communicated to the customer. The result was massively inflated customer expectations, and retrospection revealed that the teams’ estimates were about four to five times larger—and thus far more accurate--than those of the analysts.


By A O'CALLAGHAN 01 Mar, 2017

“Ready? Steady! Go!”. That phrase echoes from my youth. I used to twitch waiting for the starter to shout that phrase at the beginning of the 800m races I ran, representing my school. It was also the title of a ground-breaking pop music show which caused me to fall in love with Dusty Springfield, Sandy Shaw and every other female singer who appeared (I was a very impressionable teenager). It resonates today for me in Scrum.

When Development teams pull Product Backlog Items (PBIs), or user stories, from the Product Backlog into a Sprint they need to be ready to hit the ground running immediately after the Sprint Planning meeting. For that to happen the PBIs must be in a state that allows them to do that.


By A O'CALLAGHAN 21 Feb, 2017

The pushmi-pullyu (pronounced “push me-pull you”) is a fictional creature in “ The Story of Doctor Dolittle ,” which is described as a cross between a gazelle and a unicorn.

Recently, I was talking with a fellow software professional about some issues he was having implementing Kanban, and the pushmi-pullyu came to mind. Allow me to explain why.

Kanban’s Popularity

Kanban is the most popular agile approach after Scrum, according to the most recently published  State of Agile Survey . Scrum is, of course, massively dominant.

Only 5 percent of respondents described their teams as Kanban teams, while three-quarters used either Scrum, a Scrum hybrid or Scrumban. However, when asked what techniques they used, nearly four in every 10 teams said that they use Kanban boards.

This is might be an exaggerated figure since, in my experience, many people confuse Kanban boards with Scrum boards. They look similar, but have very different purposes.

While a Kanban board maps a value stream for the lifetime of the product, a Scrum board is a visualization of a sprint backlog, and is reset at the beginning of every new sprint.

Additionally, the Scrum board is owned by a single Scrum development team, while Kanban is agnostic about who owns the board. These differences turned out to be at the heart of the issue that my colleague raised with me.


By A O'CALLAGHAN 16 Feb, 2017

“What is the difference between an up-front requirements document and a fish?” said Gollum, hoping to catch the Hobbit out with his riddle. But Bilbo Baggins, though a Halfling, was an experienced Agilist. He knew the answer. “A fish rots from the head down, “ he said, “but a requirements documents rots from the bottom up”. “Curses!”, screamed Gollum, “You cheats us”. But Bilbo wasn’t cheating. He was just drawing on experience.

Detailing all of the requirements out up front is a colossal waste of effort in the development of software products. The average churn after the document has been signed off is said to be about 35%, although most software professionals when I ask them to give an estimate, tend to give me a much higher figure . In any case the point is, that by the time the requirement is reached, there’s a good chance it will have either significantly changed or disappeared completely from the To-Do list. The effort spent in eliciting needs, analysing them and documenting the system requirements that meets those needs has been wasted. That in turn entails a cost: the salaries of the professionals involved for a start. And now at least part of that effort and cost has to be spent again in understanding the new situation.

Read more here

By A O'CALLAGHAN 13 Feb, 2017

(Originally posted 2014)

I have recently been reading The 7th Annual State of Agile Survey (1). It has some interesting statistics. Not surprisingly, Scrum is still the dominant approach in Agile projects by a country mile. 54% of respondents use Scrum and another 11% use a Scrum/XP hybrid. The named approach with the highest reported penetration after that is Scrumban with just 7% of 'the market'. The results concerning the role of the Product Owner were much more concerning, only 51% of respondents reported that they have a dedicated Product Owner and, most worryingly of all, Product Owners are listed at the bottom of those who are most knowledgeable about Agile in their companies (only 1% of respondents chose the Product Owner).

These figures just don't add up. The Product Owner function is one of the three key roles in Scrum. You cannot truly be using the Scrum framework if there is no Product Owner in your Scrum Team, and you certainly will not be as high performing as you can be if the Product Owner does not understand Agile (let alone Scrum). So what's the problem?


Ensuring the Value of the Product

Perhaps a clue to at least part of the explanation can be found in a comment made to me recently, "The Product Owner is a kind of a waiter, yes?". For the commentator - at a client's site - the customer raises requirements just like the customer in a cafe or a restaurant. The development team, like the kitchen staff, create the solution. The Product Owner is, like the waiter, a go-between who informs the kitchen (development team) of the order and then delivers the meal (product) to the customer's table. If that was all the Product Owner had to do then there might be a good reason for either having no-one in the job at all, or rebadging some existing function (a Business Analyst, perhaps) without developing in them any special skills or knowledge about Agile.

But in Scrum, the Product Owner is responsible for the Return on Investment (ROI) in the product, and the Total Cost of its Ownership (TCO). She has to ensure the value of the product to the customer, and the value of the work done by the development team. This is a heavy responsibility: Ken Schwaber once described the Product Owner as "the one wringable neck" in the Scrum Team (2).

For sure, when the customer is not directly accessible by the developers, the Product Owner acts as a customer proxy, but to play even that aspect of the role properly requires the Product Owner to be proactive in creating an intensive collaboration with the customer to understand their Business Value Model. This is so that the relative value of the different features being requested can be understood and communicated to the developers.


Ordering Product Backlog Items vs ‘Prioritising’ Them

Many organisations understand that at least, but there is an even deeper aspect to the role of the Product Owner that has not been grasped so well. When Schwaber and Jeff Sutherland revised The Scrum Guide in October 2011 (3) they removed the references to 'prioritisation' in relation to Product Backlog Items (PBIs) and the Product Owner's responsibility for them. In too many projects this had been interpreted as the Product Owner categorising PBIs by value ('High, Medium, Low or using MoSCoW rules or something similar) and then leaving it up to the Development Team to decide what the build order of the PBIs should be in any given iteration or release. The Guide now talks about the Product Owner's responsibility for ordering the PBIs in the Product Backlog 'top to bottom'.


What is the significance of this change? Of course, the Product Owner is still seeking to get higher valued features delivered earlier than lower value ones. This typically will involve some categorisation of PBIs by value. But the Product Owner also has to take on, amongst other things, the push back from the Development Team about technical dependencies between those features, and from other stakeholders, such as System Architects, who might be pointing out some architectural issues, especially in legacy systems. Another consideration is that what the customer will expect to be seeing in any Sprint Review is not a collection of discrete "done" elements, but a small and skinny version of the product as a whole to which more 'flesh' can be added in later iterations. Any one of these concerns could lead to lower value features being bundled together with higher value ones in any given Sprint Goal.


Intense Collaboration

The point is that the intense collaboration that goes on between the customer and the Product Owner is married with an equally intense collaboration between the Product Owner and the Development Team. The Product Owner is right at the centre of some of the key relationships that make the whole thing work. It is a hugely demanding role, and one which is strategically important to the success of any Scrum-driven project.

The intensity of the collaborations does not diminish, by the way, as the project progresses. The Product Backlog is not ordered top-to-bottom once and then left alone. The weight of any of the factors that led to the initial decisions can change, and other unforeseen ones emerge, as the Scrum Team surfaces new information through the development process itself. The ordering of the Product Backlog is therefore being constantly revisited, and constantly changed as the Team, and the project's stakeholders, learn more. But remember, only the Product Owner has the authority to make those changes to the Product Backlog.

The Importance of the Product Owner

If you think about it, the ordering of the Product Backlog in Scrum is the equivalent of the 'critical path' in traditional, plan-driven management of software projects. Project Managers in those projects spend time and effort sequencing activities in such a way that the dependencies between them lead to the shortest possible sequence - the critical path. This in turn determines the ordering of the work by the developers and the scheduling of other resources. In Scrum the Development Team is cross-functional, self-organising and self-managing. No-one can tell it how to do its work. The need for managing sequences based on different activities carried out by different specialists in those activities is gone. Instead the developers self-organise around the order of the PBIs in the Product Backlog by carving out a Sprint Goal from the top that is within their capacity for development in a single Sprint. And the Product Owner 'owns' the Product Backlog. That's why the Product Owner role is so important.

It is also the Product Owner who determines when enough value has accumulated in the product for it to be released, and the Product Owner who, alone in a Scrum Team, has the authority to cancel a Sprint for whatever reason. In addition, of course, it is the Product Owner who forms an agreement about the quality standards of the project with the developers in the shape of the Definition of Done

Now, what waiter tells the kitchen when there's enough of a meal on the plate for it to be served? Or negotiates with the chef and the cooks about the quality standards of the food? In what restaurant does the waiter dictate the order in which the food items will be created?

We will talk more about the role of the Product Owner and the Product Backlog in future articles, but hopefully even in this short space we have established that the Product Owner function is one that deserves respect and attention. Product Owners in Agile teams need the authority and responsibility to do the job properly, and that means their skills have to be developed - through training, coaching, mentoring and experience - to the appropriate level. Organisations that ignore or neglect the role of the Product Owner are just storing up problems for themselves in the future.


Emerald Hill Limited



(1) 7th Annual State of Agile Development Survey. VersionOne. . 2013

(2) Schwaber,K. The Enterprise and Scrum. Microsoft Press. 2007

(3) Schwaber K., and J. Sutherland. The Scrum Guide. . October, 2011

By A O'CALLAGHAN 09 Feb, 2017

You might not have noticed, but  The Scrum Guide  was updated recently (July 2016) for the first time in three years. The changes aren’t big in terms of word count, but they are significant. So I decided I needed to update my own description (1, 2) of the Guide’s evolution.

Cumulative Flow Diagrams

Let’s deal with the smallest change first. Cumulative Flow diagrams (CFDs) have been added to the list of example ‘information radiators’ that a Scrum team might use to track its progress towards its Sprint Goal. CFDs are associated popularly with Kanban – though I think they started life in Feature Driven Development – so it might be a bit of a surprise to some to see them mentioned alongside burndown charts and task boards. Don’t worry though, it is just that – a mention. You don’t have to use any specific charts or diagrams to use Scrum, so there’s nothing fundamental being indicated here.

Scrum Values

The big change is a paragraph that reintroduces the five values of Scrum. They’ve been around since 2002 at least when they were described in a book by Ken Schwaber and Mike Beedle (3). They’ve never really gone away. Although they have not previously been mentioned in  The Scrum Guide  they have always been included in the curriculum for the Scrum Alliance’s Certified Scrum Master and Certified Scrum Product Owner courses, for example.


More Posts
Share by: