This is not contradictory!
This is how I have continuous flow with Scrum
We do Scrum and… — episode 2
We use Scrum. We also work with continuous flow. We do it all the time!
There are many misunderstandings about Scrum.
One of the misunderstandings is that you deliver your items at the end of the Sprint.
Another misunderstanding is that you determine the Sprint backlog during Sprint planning and that you can’t change it within the Sprint.
Both are not true. Scrum says that you can deliver any moment when an item is ‘done’. Also you can add items to the Sprint backlog any time when agreed between Development team and Product Owner. As long as the Sprint Goal doesn’t change.
This is how we do continuous flow with Scrum
During Sprint Planning we generally don’t know what we will be working on for the whole Sprint, but we often have a clear idea about the first 2 or 3 items. So we prioritize and plan these items only. We also determine a general sense of direction. This will be the Sprint Goal. We don’t plan items that might change, be lowered in priority or get redundant upon receiving feedback on the first items.
During the Sprint we work on the items one by one, as a team. We finish item 1, show the results to the stakeholders and reflect. Based on the outcome of the reflection and possible other information we determine if we indeed will work on item 2 next. This will almost always be the case as we had a clear idea of priority already during the planning. However, a reflection if this is still the case is vital. We inspect and adapt.
Meanwhile we are working on getting more clarity on the next items (items 4 to …) to be picked up in the sprint and put them on the Sprint backlog.
This is how we move along during the Sprint.
At the end of the Sprint we have our Sprint Review. We tell our stakeholders what we have been working on, where we stumbled upon, what lessons we learned and we show them what we have created until that moment. Then we discuss with the stakeholders what to do next as one of the sources for the Sprint Planning. Then during the Sprint Planning: rinse and repeat.
Shortening the Sprint length, is that a solution?
So, if you only have clarity on a limited number of stories for a limited time-frame, why not shorten the Sprint length? Well, sometimes we can plan for only a couple of days, other times more than a week. So this clarity on the stories varies.
I see a Sprint length of a week as the minimum feasible option to work according to Scrum. How to do the Review, Retrospective with a shorter Sprint length? Also, a 1-week-sprint does not resolve the issues when we only have clarity for a few days. I have seen suggestions to have a ‘one day sprint’. In theory this would resolve the planning issues. However I foresee a lot of overhead if you then still want to work according to Scrum. That said: we haven’t tried it and as such don’t know. It would be a nice experiment.
This is how we work in a continuous flow with Scrum. We have fixed moments of inspection and adaption: the Sprint Planning, Daily Scrum, Sprint Review, Sprint Retrospective are held with regular intervals. The Sprint backlog is fluid.
And we experiment and learn rapidly while working like this. In true Modern Agile fashion.
Did you like the article? Then it would be awesome if you’d clap 👏🏻. I am also very keen to learn what you think about this topic.
My twitter profile is https://twitter.com/WJAgeling
