Done in your Scrum Team: does it have to be releasable? Spoiler: no way Jose! There’s a road to releasable and trying Scrum can help getting there. Done vs Releasable is about the difference of doing Scrum as intended and thus gaining maximum benefit, versus the long hard road to reach that state of pure transparency.

In this post I’d like to explore the concept of the ‘done’ Increment and how this relates to the ‘releasable’ Increment. Let’s start with this awesome quote by Gunther Verheyen: “If Scrum was to be reduced to one purpose only, that would be the creation of releasable Increments of product” (slightly simplified by me). I often use this in training to underline the importance of the concept of ‘Done’ and the Definition of Done in Scrum. So the intention of Scrum, according to Gunther and me (a.o.) is to create a releasable Increment.

When we create a releasable Increment every Sprint, we create Transparency by enabling true Inspection and Adaption with real market feedback. Releasing the Increment provides us with quantitative feedback (usage statistics) as well as qualitative feedback. We get this benefit by ensuring maximal transparency and applying short Inspect & Adapt (feedback) loops to the Product itself (aka the Increment) and the way we develop it. The transparency of the Increment, the team’s shared insight into this transparency and the work needed to maintain or improve this transparency is codified in the Definition of Done. But more on that in other posts (past & future).

To get back to this post: we’re discussing ‘releasable’. What’s up with that? How does it help to not actually get market feedback, but just be ‘potentially’ able to release? Having no work left to do creates transparency on the forecast of further goals we want to reach. With work remaining (i.e. not yet releasable at the end of Sprint), it is hard to forecast new work as we have to also take into account the remaining steps to take to actually release to market.

In the picture below, I’ve tried to make clear that while we must aim for creating as much transparency as possible, we should also consider the road to that situation when discussing Scrum. The beauty of Scrum is that we can ‘just start’ in whatever our current non-ideal situation is and apply the empirical process to iterate towards effective Scrum to increase the benefits from the empirical process and the Scrum framework. And while the left side is not yet ‘correct’ Scrum, since we do not conform to the rule of the releasable increment every Sprint, there is benefit in attempting Scrum and being able to benefit in many ways. Just not the full transparency promised by the releasable Increment.

From not yet releasable to releasable and beyond to full quality

  • Left, red: we often start at not completely releasable. Whatever this means to you. may go as far as we only get ‘dev done’. I would recommend to focus on getting to Releasable fast to enable major benefits of Scrum.
  • Center, blue: releasable – all skills and actions in the team and in the Sprint to create a releasable increment without additional work needed outside of sprint/team.
  • Right, green: our definition of done covers the optimum level of quality both in serving the customer need as in build quality and maintainability (and everything else needed)

Leave a Reply

This site uses Akismet to reduce spam. Learn how your comment data is processed.