Sprint Reviews With Kanban

“A good review from the critics is just another stay of execution” — Dustin Hoffman

I’ve always been intrigued by the different ways in which Scrum Teams go about their Sprint Reviews. It isn’t as though I coach a range of techniques, and suggest that teams just pick whatever format they like. My usual coaching battle is normalizing the practice of having a Sprint Review at all.

You see, Sprint Reviews are the last thing many teams wish to think about. By the time it gets to the end of an iteration, they often still have undone work crying out for attention from the task board. The time needed to prepare and conduct yet another “Scrum meeting” is not typically seen to be a priority under such conditions. Furthermore, we must contend with the very human desire to gloss over and preferably ignore any apparent failure or potential source of shame. The forecast made in Sprint Planning could have been way off, for example, and the opportunity to replan in each Daily Scrum might not have been taken as seriously as it ought to have been. Any commitment to a Sprint Goal could have evaporated with the morning dew long ago.

Which team in their right mind would want to review the sorry tale of the last Sprint, with its undone work, unresolved dependencies, unrealized hopes, and imprudently wrought ambition? A Sprint Review can appear to be, at best, a depressing rumination upon goals that were impossibly set and of promises that were impractical to keep. At worst, a Sprint Review can horrify a team, like a sadistic punishment drawn from the rulebook of a 19th Century navy. “Why should we visit such a terrible barbarity upon ourselves?” team members mutter under their breaths. It can seem to them that, by deliberately preparing for a Sprint Review, they are knotting and handing over the very lash with which they will be flogged.

This can hardly be described as the right agile spirit, and a Scrum Master’s greatest challenge often lies in coaching teams to value each Scrum event as an inspect and adapt opportunity. In the case of a Sprint Review, the purpose is to inspect the increment — in whatever state it might be — and to adapt the Product Backlog in light of evolving business conditions. It is a review of the work that has been done, and of any work that has not been done and which still ought to be completed. There should be no hidden subtext of blame. Rather, by considering undone and remaining work with the Product Owner and invited stakeholders, there is an opportunity to replan the backlog for the most advantageous outcome in the future.

Even so, this can all ring hollow when organizations are slow to change, and the avoidance and allocation of blame continue to be valued as an important management skill. In fact — judging by what I’ve seen — the principal driver behind Scrum Teams wanting to ditch Scrum and adopt Kanban is their wish to avoid the pain and spectacle of having to undergo Sprint Reviews. More often than not, that’s what lies behind it. The potential value of switching to a flow-based way-of-working doesn’t seem to figure much in the equation at all. Nor does any loss in the ability to mitigate serious risk, given that the team would no longer try to achieve significant goals, on cadence, in a complex product environment. This can hardly be described as the right agile spirit either.

Kanban is sometimes thought of as a soft option because “flow” is misinterpreted as “whatever gets delivered gets delivered”. A team will start with what it is, realistically, doing now. There is no need to vamp Sprints. The odious Sprint Goal and the contrived forecast of work in the Sprint Backlog are dispensed with. It looks as if the team can no longer be held hostage to fortune. In Kanban there is no Great Lie to be fabricated about a planned Sprint outcome, and, it is assumed, there is no great commitment that can hang over team members’ heads like the Sword of Damocles. What possible use for a monstrous Sprint Review can there be? Instead, there ought to be a succession of mini-reviews with the Product Owner as each item is completed. 

Having mini-reviews can be useful and timely, and they are all very well. In truth, however, a professional Kanban team will not escape from making a serious commitment, nor would a team ever seek to do so. For one thing, its members will need to understand and define a commitment point in their workflow. This is when they clearly assume responsibility for a work item, and undertake to complete it in line with explicit policies that address time and quality. A Kanban team might articulate a “Service Level Expectation” to stakeholders, for example, in which a certain percentage of items will be completed within a certain time-frame.

The idea of dispensing with the Scrum Framework can seem less attractive once the rigor that underpins Kanban is brought into focus. It is no soft option. The team would be held accountable for the service they provide. In effect, team members can expect to be held accountable as regularly and as surely as they set the expectations of stakeholders. Perhaps there still needs to be something like a Sprint Review after all...an event through which the likes of SLEs are inspected and adapted, without blame or rancor, and through which the most recent team experiences can be acted upon or at least taken into account.

A case can thus be made for not necessarily replacing Scrum with Kanban, but rather for implementing a Kanban strategy within Scrum. Doing so can support and reinforce the classic application of Scrum in complex and uncertain environments. At an elementary level, this might mean optimizing flow to better achieve a conventional Sprint Goal, such as the delivery of a significant feature around which a Sprint Backlog forecast might flex in a controlled and work-limited manner. 

The critical thing about a Sprint Goal is that it has to give team members a reason to work together during the Sprint, and not to drift apart on separate initiatives. Surprisingly conventional implementations of Kanban are in fact possible. Remember that the understanding of a “product” is quite broad in Scrum, and it might well amount to the provisioning of a service. In certain sprints, the Goal could be to provide and meet an agreed SLE, whereas in others the traditional mitigation of feature risk could be more important. In Scrum, a Sprint Goal can be any coherent and valuable functional outcome. A team may reasonably choose to focus on improving the flow of work, rather than on the delivery of a particular feature. A Sprint Review might start with an SLE, then turn from this to cycle times, the maximum work item age, any classes of service being observed, and the rate of throughput. The Product Backlog might be adapted to better support desired outcomes, such as by breaking items down into smaller units of value. A Monte Carlo analysis of the items completed could also be a topic for discussion, as it may inform the team about the commitment they ought to make in the future.

In conclusion, the format in which Scrum Teams conduct their Sprint Reviews can be as varied as the work itself, and the expected outcome of doing it. If team members have been focused on feature delivery, a “demo” of some new capability might be the keystone of the event. If the focus has indeed been more upon flow, then the emphasis might be on Service Level Expectations and any associated metrics of production. Then again, the right format for a given Sprint Review might lie somewhere in between. Many options are available when implementing Scrum with Kanban. The important thing is to recognize the irreducible purpose of holding a Sprint Review in the first place.