Developer-Ordered Work Plan
(Why Gantt Charts Don't Work)
... the Developers have a Sprint Backlog created by selecting a number of Product Backlog items from the top of the backlog in accordance with the team's Velocity. They have started a Sprint, and are seeking insight on how to get started and how best to order elements of the work plan.
✥ ✥ ✥
There is only one time that Scrum demands an attitude of firm commitment: when the Developers forecast to deliver the entire Sprint Backlog at the end of the current Sprint. The Team does its best to be able to deliver according to its 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.
Scrum developers sometimes have difficulty understanding The Spirit of the Game: that control of the Sprint lies in their hands. 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 at the end of the Sprint 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 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 commitment to the market.
Optimally ordering the Sprint Backlog is a challenge. If there are five PBIs and each has 9 Sprint Backlog Items (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 are really fast and 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, supposedly paraphrasing Nonaka, 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 order 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 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.
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. 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. The Product Owner has a reasonable right to develop marketing plans on the basis of the Developers' forecast. It dis-incents the team to ask them to deliver the most important work items first, when they are striving to deliver the entire work plan. Sometimes the Developers fail to delivery the entire Sprint Backlog, but that is a natural consequence of Emergent Requirements. The Team may be able to learn from an incomplete delivery, but it's unwise to pretend to be omniscient enough to create the most valuable ordering if it sacrifices the self-organization that bodes for getting the best long-term value.
Let the Developers decide the best ordering of tasks to reach their forecast of delivering the 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 a statistically responsible ordering instead of an arbitrarily, externally constrained ordering.
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. 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 ways of ordering tasks that build on their engineering strengths, and knowledge of how best to organize their own work.
Of course, any Product Backlog ordering that owes to 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. This can also help the team focus on First Things First.
Teams should strive to be on top of dependencies 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 Stop the Line.
In the Scrum Handbook, Jeff Sutherland writes, "The team choses the ordering of Sprint Backlog tasks to maximize the velocity of production and quality of 'done' functionality."