Work can flow across the Sprint boundary

There is nothing in the Scrum Guide that explicitly prevents work from flowing across the Sprint boundary. In fact, allowing flow across Sprints, without compromising the Sprint Goal, is a pragmatic strategy that enhances delivery, throughput, and responsiveness to customer feedback.

For practical guidance, explore the Kanban Guide for Scrum Teams, and consider attending a Professional Scrum with Kanban class.

TL;DR

The Definition of Done ensures transparency and quality and is non-negotiable. The Sprint Goal must articulate clear, measurable business outcomes or customer benefits. Effective flow requires reducing batch sizes, allowing unfinished work to cross Sprint boundaries strategically. Professional Scrum Teams adept at consistently delivering Done increments significantly enhance their throughput by embracing flow principles and rapid feedback cycles.

A Sprint serves primarily as a container for planning, not always for delivery. Just as Continuous Delivery integrates seamlessly with Scrum, incorporating flow through Kanban complements and strengthens Scrum practices. All teams can benefit from this approach, provided they consistently achieve clear, outcome-focused Sprint Goals and maintain transparent, Done increments.

Managing Work Across Sprint Boundaries

Allowing work to flow across Sprint boundaries is an advanced yet beneficial technique. Initially, many teams struggle as they rarely achieve truly Working Software or fully meet their Sprint Goals by Sprint’s end. Transitioning to a mindset of flow and continuous validation is crucial for agile maturity.

My early scepticism around flowing work across Sprints shifted through deeper discussions with colleagues like Steve and Daniel. The critical insight was distinguishing the necessity of a Done Increment from the expectation that all Product Backlog Items (PBIs) must be completed by Sprint’s end.

Teams practicing Continuous Delivery (CD) inherently create working software incrementally and continuously. Such teams typically automate every aspect of their Definition of Done. Thus, by the Sprint Review, presenting completed increments is straightforward and predictable.

For a professional Scrum Team, adopting CD is foundational, not optional.

Strategic Sprint Goals and Continuous Value

Good Sprint Goals clearly articulate measurable outcomes or customer benefits rather than listing features or technical tasks. These goals act as strategic stepping stones toward your broader product or business roadmap, enhancing the clarity and alignment of your team’s efforts. Poorly constructed Sprint Goals, focused merely on delivering bundles of functionality or technology, often fail to communicate explicit and measurable benefits.

Aim to deliver multiple increments within a single Sprint, frequently gathering user feedback to continuously inspect and adapt progress toward your Sprint Goal. Regular increments and rapid feedback loops foster empirical control, allowing the team to pivot swiftly based on emerging insights or market changes.

Minimal Sunk Costs and Strategic Investment

Organisations invest in products or services one Sprint at a time. Each Sprint represents a potential decision point: assessing product-market fit and deciding whether continued investment is justified. The ultimate aim is to minimize sunk costs, banking created value incrementally and evaluating whether the product should continue development, transition to maintenance, or be marked end-of-life. Effective Sprint Goals and transparent increments support informed strategic decisions, ensuring resources align with business outcomes.

Shipping Software with Unfinished PBIs

Flow necessitates disciplined engineering practices ensuring early, frequent validation through automation. Key practices significantly enhancing CD include:

• Feature Toggles – Enable controlled exposure, A/B testing, and experimentation. Temporary toggles must be systematically removed through refactoring upon feature completion.
• Refactoring – Regularly restructure code for clarity, maintainability, and responsiveness to customer feedback.
• Test Driven Development (TDD) – Validate code functionality continuously, supporting confident incremental changes and refactoring.

While complementary, these practices are fundamental to robust CD frameworks. Experimentation and iterative improvements tailor their application effectively to your context.

Aligning Flow with Scrum Principles

The Scrum Guide mandates a Done increment each Sprint for transparency. Without transparent increments, empirical control suffers, undermining Scrum itself.

Unfinished Backlog Items differ fundamentally from incomplete (“undone”) work.

Flowing work between Sprints is permissible within Scrum if aligned with clear Sprint Goals and delivering usable increments:

• Sprint Review – Teams collaboratively inspect completed increments, openly discuss incomplete work, and revise the Product Backlog based on stakeholder insights and measurable outcomes.
• Sprint Planning – Establishes clear goals and forecasts achievable work items, ensuring alignment with delivering increments and measurable Sprint Goals.
• Sprint Goal – Provides strategic focus. Teams can integrate additional work provided primary Sprint Goals remain achievable, enabling strategic decision-making based on ongoing feedback.

Regularly revisiting the Scrum Guide, emphasizing empirical control, and maintaining Scrum Values ensures successful flow integration within Scrum. Consistently verify increments against the Definition of Done and fulfil measurable Sprint Goals.

For further insights, review the Kanban Guide for Scrum Teams and consider participating in a Professional Scrum with Kanban course.