blog

Work can flow across the Sprint boundary

Published on
6 minute read

There is nothing in the Scrum Guide that says that you can’t have workflow across the Sprint boundary. I’m going to suggest that not only can you, but you should as long as you don’t endanger the Sprint Goal.

UPDATE: To find out how to allow work to flow across the Sprint boundary you can read the Kanban Guide for Scrum Teams  **, and schedule a** Professional Scrum with Kanban  class.

TL;DR;

The definition of Done  is an instrumental part of maintaining Transparency of the past work and is not optional. The Sprint Goal provides focus and direction. In order to maintain flow we need to be able to reduce the batch size of the work, thus we must allow for work to flow across the Sprint boundary. If you have a Professional Scrum Team that is adept at creating Done increments of working software  then introducing flow can improve the value delivered by increasing the throughput of the team.

Work can flow across the Sprint boundary

Always remember that the Sprint is a container for Planning and not always for Delivery. Just like you can do Continuous Delivery in Scrum, so you can also introduce flow and Kanban. Less skilled teams can also benefit as long as you make sure that you meet the Sprint Goal and Done Increments are created to provide transparency of the past and build trust for the future.

Starting Work that the Development Team knows that it can’t finish

Although you will not find anything in the Scrum Guide that prevents you from flowing work across Sprints you should consider it an advanced technique. Most teams that I work with are not even at the point where they have Working Software at the end of the Sprint and they are often only just achieving their Sprint Goal.

I also believed the myth that we could not flow work across the Sprint boundary. It took a long conversation with Steve and Daniel to kindle a different idea, and long discussions over a beer to make it concrete. My argument went; “If you have to be Done by the end of the Sprint then how can you have any unfinished work?” My argument was wrong! I was confusing the need to have a Done Increment with all of the PBI’s being finished.

If you as a Development Team are practising Continuous Delivery (CD) then they always have working software. I would expect that a team doing CD would have every single element of their Definition of Done (DOD) automated and every Checkin/Pull Request meets the DOD. If that’s true, then when you get to your Sprint Review you just show the work that you have finished.

If you want Flow then CD is no longer optional for a Software Team let along a Professional Scrum Team  **.**

Shipping software with Unfinished work can still be Scrum

There are a number of Engineering consideration that a Development Team will need to take into account if they want to focus on Flow. With CD comes the need to validate early and often, with automation, so that you don’t have to stop and check everything manually. There are a number of practices that can help:

All of these are optional complementary practices that help you achieve CD but it is not an exhaustive list. There are many other practices that will help, try them and see what works for your team.

While the Scrum Guide does not say that you need to do CD let alone the practices I have listed above, it does require that you create an Increment of Working Software at least once per Sprint. Anything less and you have no transparency of what was done. With no transparency, you lose your empirical process control, and without empiricism, you are not doing Scrum.

Unfinished Backlog Items are not the same as Undone work.

How does this impact Scrum elements?

Within the bounds of the Scrum Framework, you are allowed to flow work from one Sprint to another. The Result is still Scrum if we have working software, and we meet the Sprint Goal.

I have found that reading the Scrum Guide carefully, turns up all sorts of miss conceptions that we all have as we interpret and use Scrum. If you are not sure, re-read the Scrum Guide, maintain the Scrum Values, focus on empirical process control and maintain transparency.

At the end of every Sprint, you should have working Software that meets your definition of Done and you should have met your Sprint Goal.

UPDATE: To find out how to allow work to flow across the Sprint boundary you can read the Kanban Guide for Scrum Teams  **, and schedule a** Professional Scrum with Kanban  class.

news-and-reviews blog developers flow scrum the-sprint

Connect with Martin Hinshelwood

If you've made it this far, it's worth connecting with our principal consultant and coach, Martin Hinshelwood, for a 30-minute 'ask me anything' call.

Our Happy Clients​

We partner with businesses across diverse industries, including finance, insurance, healthcare, pharmaceuticals, technology, engineering, transportation, hospitality, entertainment, legal, government, and military sectors.​

YearUp.org Logo
Emerson Process Management Logo
Big Data for Humans Logo
Hubtel Ghana Logo
Workday Logo
Xceptor - Process and Data Automation Logo
DFDS Logo
New Signature Logo
Schlumberger Logo
Qualco Logo
Lean SA Logo
SuperControl Logo
Akaditi Logo
Lockheed Martin Logo
Milliman Logo
Slaughter and May Logo
Genus Breeding Ltd Logo
Cognizant Microsoft Business Group (MBG) Logo
Washington Department of Transport Logo
New Hampshire Supreme Court Logo
Washington Department of Enterprise Services Logo
Department of Work and Pensions (UK) Logo
Ghana Police Service Logo
Nottingham County Council Logo
Graham & Brown Logo
MacDonald Humfrey (Automation) Ltd. Logo
Jack Links Logo
Flowmaster (a Mentor Graphics Company) Logo
Qualco Logo
Capita Secure Information Solutions Ltd Logo