Scrum Guide change: Planning Retrospective items into a Sprint Backlog

"To ensure continuous improvement, [the Sprint Backlog] includes at least one high priority process improvement identified in the previous Retrospective meeting." - The Scrum Guide, November 2017 

That old familiar feeling

Have you ever had a sense of déja-vu in a Sprint Retrospective? You know, the feeling that you had been at that same event before, where people said exactly the same things? It's a common situation and yet there's nothing spooky or preternatural about it. Time and again opportunities for improvement are identified in a Retrospective...and nothing is actually done about them. Once the next Sprint is under way, all too often team members are so busy focusing on development work they never think about anything else. Those carefully elicited process improvements are not translated into action items which are planned, prioritized, and tracked through until implementation. Usually they are lost somewhere between the Sprint Retrospective and the next Sprint Planning session, and then forgotten about completely once development work cries for attention from the task board. It isn't enough for a process action to have an owner...not when "real" work needs to be done. Improvements slip into the fog of what might have been, until it is too late. Only when the next Sprint Retrospective is held are the same unsolved issues dragged out of the ditch they were rolled into and their bloody features recognized again.

Clearly this makes a nonsense of Sprint Retrospectives, as they can serve little purpose if improvements are not carried through. Some teams, acting out of embarrassment or exasperation at this show trial of their repeated failings, then abandon Retrospectives altogether as though they were a kind of waste. One dysfunction is thereby replaced with another until the team no longer even hopes to inspect and adapt.

Planning improvements into a Sprint

Sometimes teams can fall prey to the very focus we wish them to exhibit. Focus is, after all, one of the Scrum values and an inattention to items which lie outside the planned body of work might even be seen as a virtue. When teams recognize this, they might choose to expressly plan retrospective improvements into the Sprint Backlog to make sure they remain transparent and are not forgotten.

The November 2017 update to the Scrum Guide explicitly ratified this practice. "To ensure continuous improvement, [the Sprint Backlog] includes at least one high priority process improvement identified in the previous Retrospective meeting", it advises. What does this really mean though? How can a team decide what should count as a "high priority" improvement, for example?

Well, if a certain process improvement is disjoint to the delivery needs of the next Sprint, then it may be hard to make the case that it is “high priority” at all. Remember that process changes are not made in isolation of empirical value delivery considerations, and improvements ought to be made in a timely and considered way that maximizes the value delivered each Sprint. It is reasonable for Development Teams to take ownership of specific improvement objectives (or portions thereof) which they consider to be valuable and achievable. The new guidance introduced in November 2017 is, essentially, to make these visible in the Sprint plan.

Wider improvements

Not all actions from a Retrospective necessarily fall to a Development Team to implement. For example a Product Owner may take away certain actions which he or she prioritizes in order to help maximize value delivery, but those actions would not necessarily be planned into the Development Team’s Sprint Backlog.

Process improvements ought to be selected in a timely way, so as to maximize the empirical delivery of value Sprint by Sprint. This means that where multiple teams need to collaborate, they should agree which improvements are most likely to enhance the value of the next integrated increment and are achievable. Each team should then action those improvements, or their relevant contributions to their implementation. The most useful improvements from a Nexus perspective are those which are likely to enhance integration capabilities.

Scrum often requires deep and pervasive change across an enterprise, and those changes are typically far more than Development Teams can accommodate even in aggregate. Those teams can face multiple dependencies outside their control and there is usually an organizational gravity to overcome. Scrum, however, is not a transformational framework and hence there is no prescription for effecting changes which lie beyond a team’s present competence, even if they are of critical importance. That’s where other frameworks such as Agility Path and Evidence Based Management may be expected to come in, and a distinct "transformation backlog" may be needed to help achieve transparency over the wider change process.