...the Development Team has created a work plan—a Sprint Backlog—from a Sprint’s worth of Product Backlog Items pulled from the top of the Product Backlog in accordance with the team’s velocity (see Notes on Velocity). It has started a Production Episode, and is seeking insight on how to start building the Product Increment or to sustain yesterday’s momentum by best ordering the work plan.

✥       ✥       ✥ 

There is only one time that Scrum demands an attitude of firm commitment to a specific objective: when the Development Team forecasts to deliver the Sprint Goal by the end of the current Sprint. And sound Scrum Teams, on the average, meet their forecasts for delivering the Sprint Backlog. The team plans in advance to create forecasts for the next two or three Sprints, but only the current Sprint is a unit of planned achievement. Of course, even this plan can miss the mark due to emergent requirements, but a well-run Scrum Team delivers regularly enough on its forecast that it can be depended upon to support the business.

Even Scrum practitioners sometimes have difficulty understanding The Spirit of the Game: that control of the Sprint lies in their hands. It’s easy to lose sight of the autonomy that Scrum teams enjoy when they direct their focus toward stakeholders’ expectations and to the team’s commitments. The team commits to the Sprint Goal at the beginning of the Sprint. Some Scrum Teams argue that they should also create a work plan that follows the original ordering of the Product Backlog Items (PBIs). If they do this, then argue that some Sprint Backlog Items (SBIs) will be left unfinished at the end of a Sprint, they can have the satisfaction of at least having completed the most important items. But that mindset leads to complacency: the Development Team may lose its incentive to burn down the Sprint Backlog contents to zero. It leads to a practice of “we commit but...” that robs the term forecast of any attitude of commitment, and leaves the Product Owner insecure about his or her own ability to manage commitments to the market.

Optimally ordering the Sprint Backlog in advance is a challenge. If there are five PBIs and each has nine SBIs, then there are 45 factorial possible orderings (about 2 x 10⁵⁶)! In addition to those original SBIs, emergent requirements cause the team to add new ones as the Sprint progresses (or, in some cases, to remove some). Some orderings enable really fast development while others are really slow, and that ordering changes every day. It’s the essence of Scrum for the team to figure out what the fastest ordering is. That’s what the Daily Scrum is for.

The Product Owner has no say over how the team achieves its forecast. Ken Schwaber, paraphrasing Nonaka ([1], p. 85) says: “The team has full authority and is autonomous during the Sprint.” The Product Backlog ordering reflects the Product Owner’s wishes. While Product Owners certainly have the final authority over the ordering of the PBIs, they have no authority over how the Development Team organizes its work. If the work plan follows the PBI ordering, it creates a leak in the firewall (see Firewall) between the Product Owner and the Developers, letting the Product Owner tacitly direct or disrupt the Development Teams’s organization of work.

If the Developer work plan follows the Product Backlog ordering, and market priorities change mid-Sprint, the Product Owner can argue to intervene in the delivery order. This amounts to the Product Owner meddling with the Developers mid-Sprint. If this happens and the Development Team fails to deliver at the end of the Sprint, it is easy to blame the Product Owner’s intervention, and it is difficult to believe that the same won’t happen again in a subsequent Sprint. That saps the Development Team’s will to care at all about what it will or won’t complete in a Sprint.

Such a forced work plan can over-constrain an immature Development Team that is not a perfectly Cross-Functional Team. For example, if there are few database people on the Development Team and if the top PBIs are database-intensive, and if the Development Team is practicing One-Piece Continuous Flow, then this keeps the team from making progress on PBIs that better fit the available skill set. On the other hand, the Development Team members may discover new opportunities to invest in learning and working outside their primary skill sets, which in the long term will increase multi-skilling team agility if it adjusts the work plan in that direction.

When impediments disrupt the Sprint flow, it lowers the value that the Developers can deliver during a Sprint. It’s important to keep development flowing when an impediment arises, yet pre-arranged work plans cannot foresee these exceptions. Furthermore, folks outside the Development Team have difficulty understanding how to navigate the myriad options at hand to deal with these impediments in a way that will preserve the greatest value.

The Development Team forecasts delivery of the entire Sprint Backlog to the Product Owner. The Sprint Backlog often represents a unit of market delivery; that is, at the level of the market campaigns, the Product Owner should be able to treat the entire contents of the Sprint Backlog as a minimal marketable feature: a Product Increment. The Product Owner has a reasonable right to rely on the Development Team’s forecast to drive soft marketing plans. The Development Team becomes disincentived if the Product Owner asks it to attack the most important work items first, while it is instead striving to complete everything. Sometimes the Development Team fails to deliver the entire Sprint Backlog as a natural consequence of emergent requirements. The team may be able to learn from an incomplete delivery, but it’s unwise to externally impose even the best-intentioned work ordering constraints if the team sacrifices the self-organization that optimizes the chance of delivering the best long-term value.

Therefore:

Let the Development Team members decide the best ordering of tasks to reach their forecast of delivering the Sprint Goal and full Sprint Backlog. The Development Team should self-organize to do work in the order it believes will incur the lowest cost or least time or, alternatively, to support the highest overall value. Let the Product Backlog ordering inform, but not drive, these decisions. The Development Team takes the initiative to create an informed and responsible ordering instead of an externally constrained ordering that is arbitrary with respect to emerging development requirements.

As items’ granularity becomes finer and finer, the constraints on ordering items within a grouping (first, by Sprint; second, by PBI) becomes less and less stringent.

✥       ✥       ✥ 

The result is an ordered work plan that builds on flexibility and uses the Development Team’s collective insights to best support the business goals—embodied in the Sprint Goal—for the Product Increment. The Development Team reviews the plan daily and may update it frequently in response to the team’s progress, to changing market conditions, the Sprint Goal, and all other insights at the disposal of the Developers. It’s about the team being in charge: how can the Development Team members self-organize if someone tells them how to do things? It is the ScrumMaster’s job to motivate the team to this level of self-organization.

As with the weather, the amount of work the team anticipates completing during the Sprint is a forecast or estimate rather than a promise. The forecast is based in part on recent historical performance; see Yesterday’s Weather. Further, the plan is dynamic: the team updates it every day at the Daily Scrum.

If the Development Team creates its own work plan ordering, then it is better able to self-organize without undue influence from the Product Owner. The Development Team is free to find task orderings that build on its engineering strengths, and knowledge of how best to organize its work. This can be liberating, particularly for a team that has suffered being micromanaged, but it is also a call to responsibility, discipline, and a sense of ownership for the work plan. Growing into this sense of responsibility and ownership requires focus, and can often benefit from the guidance of the ScrumMaster, particularly as the team makes its journey out of micromanagement into the realm of Autonomous Teams.

Of course, any Product Backlog ordering dictated by foreseeable engineering dependencies between PBIs will also appear as a dependency between work plan items. The Developers can use this information to properly order the work plan to satisfy technical dependencies.

Overly casual ordering of work plan items can lead to a large number of partially completed PBIs at the end of the Sprint. To remedy this, use One-Piece Continuous Flow.

Some Scrum traditions honor an approach called “First Things First,” which makes it incumbent on the team to deliver Product Backlog Items in their order of appearance on the backlog. The idea is that the team doesn’t have to waste time agreeing on an ordering, and that following the PBI ordering best honors the Product Owner’s wishes. We feel that this is an indirect way for the Product Owner to control the team and to dilute the team’s ability to be self-managing. Such external constraints are likely to reduce the team’s velocity, because they frustrate optimizations that the team can realize by reordering the work plan.

Teams should strive to resolve dependencies between items by mid-Sprint: see Dependencies First. If the Product Owners feel that their inability to control the team work program puts crucial PBIs items at risk, they can mitigate the risk either with the Sprint Goal or by making a strategic adjustment to the Sprint length.

Consider the situation where the Product Owner must react to an unforeseen market shift by immediately delivering a PBI from the current Sprint. The Product Owner can reorder the deliverables—but only by making the exception visible and forcing the issue with Emergency Procedure. Only in the most experienced and mature Scrum Teams might it be acceptable for the Product Owner to negotiate the ordering of the Development Team's work plan, but even then only with the Development Team's consent.

In [2] (pp. 23–4), Jeff Sutherland writes, “The team chooses the ordering of Sprint Backlog tasks to maximize the velocity of production and quality of ‘done’ functionality.” See Definition of Done.

Compare and contrast with One-Piece Continuous Flow and Informal Labor Plan.

[1] Ikujiro Nonaka and Hirotaka Takeuchi. The Knowledge-Creating Company: How Japanese Companies Create the Dynamics of Innovation. Oxford, UK: Oxford University Press, 1995, p. 85.

[2] Jeff Sutherland. The Scrum Handbook. Somerville, MA: STI Press, July 2010, pp. 23–4.

Picture credits: Shutterstock.com.