Developer-Ordered Work Plan

(Why Gantt Charts Don't Work)

Developers together decide the ordering of work items, day by day

... the Developers have 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. They have started a Production Episode, and are 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 Developers forecast 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 towards 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 they argue that at the end of a Sprint that leaves some Sprint Backlog Items (SBIs) unfinished, then they can have the satisfaction of at least having completed the most important items. That leads to complacency: the Developers may lose their incentive to burn down the Sprint Backlog contents to zero. It leads to a practice of “we commit but ...”, 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 1056)! In addition to those original SBIs, emergent requirements add new ones as the Sprint progresses (or, in some cases, cause some SBIs to be removed.) 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. Jeff Sutherland observes, “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], 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 Developers organize their work. If the work plan follows the PBI ordering it creates a leak in the firewall between the Product Owner and the Developers, letting the Product Owner tacitly direct or disrupt the Developers’ 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 Developers fail 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 Developers’ will to care at all about what they 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 Developers and if the top PBIs are database-intensive, and if the Developers are 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 Developers may discover new opportunities to invest in learning and working outside their primary skill set, which in the long term will increase multi-skilling team agility if they adjust the work plan in that direction.

If the Sprint is beset by too many impediments, then this caps the value that the Developers can deliver during a Sprint.

The Developers forecast 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 develop soft marketing plans on the basis of the Developers’ forecast. It dis-incents the Developers if the Product Owner asks them to attack the most important work items first, while they are instead striving to complete everything. Sometimes the Developers fail 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 they sacrifice the self-organization that optimizes the chance of delivering the best long-term value.


Let the Developers decide the best ordering of tasks to reach their forecast of delivering the Sprint Goal and full Sprint Backlog. Developers should self-organize to do work in the order they believe 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. Developers take 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 the granularity on items 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 Developers’ collective insights to best support the business goals for the Product Increment. The plan is reviewed daily and may be updated frequently with regard to market conditions, the Sprint Goal, and all the other insights at the disposal of the Developers. It’s about the team being in charge: how can the Developers self-organize if someone tells them how to do it? It is the ScrumMaster’s job to motivate the team to this level of self-organization.

If the Developers create their own work plan ordering then they are better able to self-organize without undue influence from the Product Owner. The Developers are free to find task orderings that build on their engineering strengths, and their knowledge of how best to organize their own work. This can be liberating, particularly for a team that has suffered being micro-managed, 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 a transition out of micro-management into the realm of Autonomous Teams.

Of course, any Product Backlog ordering that owes to foreseeable engineering dependencies between PBIs will be reflected 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 that the team doesn’t have to waste time agreeing on an ordering, and that the Product Owner’s wishes for ordering are best met. 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.

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 Sprint Goal or by shortening the length of future Sprints. If the Product Owner must react to an unforeseen market shift that could be mitigated by early release of one of the current PBIs, then the Product Owner can affect a re-ordering of deliverables — but only by making it visible with Emergency Procedure.

In the Scrum Handbook [2], Jeff Sutherland writes, “The team chooses the ordering of Sprint Backlog tasks to maximize the velocity of production and quality of ‘done’ functionality.

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

[1] Ikujira 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, p. 22.

Picture from: