Fixed Work
Developers change hats to work with the Product Owner at prearranged intervals, and then return to developing.

... you are organizing the work of the enterprise, and the Product Owner is looking for ways to get help from the team to prepare requirements and the Product Backlog.

Scrum divides time in two. There is a continuous time line for analysis and the business, and a cyclic Sprint time line for production. Time for analysis and innovation is impossible to estimate and may unfold over long intervals, because it arises unpredictably in a process that Steve Johnson calls “the slow hunch.” [1]

✥       ✥       ✥ 

All work must be accounted for if the Product Owner is to use team velocity for release planning, yet not all development work can be time-boxed. For example, the team cannot foreordain the moment at which they will have progressed enough towards creating a Refined Product Backlog to pronounce any single Product Backlog Item as being Ready. There is always fixed, recurring work that is not accounted for in Development Team estimates.

The Product Backlog is the primary tool for budgeting the work for a product development. Its Product Backlog Items (PBIs) are ordered by the Product Owner who takes development estimates into consideration when planning deliveries. Teams are expected to eventually commit to the Sprint Goal and to be confident about their estimates. That work takes time. Developers are responsible for fitting all work within the bounds of a Sprint.

Usually, Developers can forecast only the development tasks that are tied to their skill set, experience, and area of responsibility. Other work may be difficult, or impossible, for the developers to estimate. For example, some analysis tasks require open-ended research to evaluate development feasibility, cost, and tradeoffs. While analysis is usually the Product Owner’s job, such analysis often requires input from or work by the Development Team. You can try to time-box such research, but that can lead to repeated extensions of the research time box. And while research activities produce insights, they rarely produce the kind of Potentially Shippable Increment expected from work done during the Production Episode — the development part of a Sprint. This raises doubts about doing such work within the Sprint, and about budgeting it on the Product Backlog: if it is not producing product, it is some form of waste.

This wouldn’t be a problem if the Product Owner Team alone could do the research, because the Product Owners can manage their own time. However, it is often the case that Product Owners have a strong business skill set but a weaker skill set to actually build the artifacts to be evaluated. Yet issues of technology and production often arise as key elements of business risk and, as such, fall within the Product Owner’s purview.

Scrum tradition comprises other activities whose work is not tracked on the Product Backlog. Examples include the time spent on Sprint Planning, Sprint Review, drag (e.g., the time we spend drinking coffee or networking in the office), the Sprint Retrospective, and time focused on maintaining a Refined Product Backlog.


Divide all Developer tasks into those that can be estimated (such as work on the product) and those that cannot (such as the work to understand requirements as the team moves PBIs to Ready). In each Sprint, plan to work on just enough estimated tasks to fill the Production Episode time box. Set aside periodic time-boxes for non-estimable work, outside the Production Episode budget, and complete as much of each kind of such work as time-boxing allows. Each Sprint, the Scrum Team does only as much of a given kind of work (e.g., analysis work, business planning, review activities) as will fit inside the corresponding time box for such work. Move this work into events such as Sprint Planning, the Sprint Review, the Sprint Retrospective, and time boxes where the whole Scrum Team works to continuously maintain a Refined Product Backlog.

If the team feels that work on any set of non-estimable tasks is complete for the time being, there is no need to fill out the corresponding time box with work. For example, if the team finishes Sprint Planning before its time box is up, the Developers can immediately move on to the Production Episode.

✥       ✥       ✥ 

Now, the Development Team can sustain work on items that are difficult to estimate, such as tasks that require fundamental innovation or which otherwise entail high uncertainty. Removing such work from the Product Backlog, and therefore from Production Episode time, allows the work to proceed at its own pace. Tasks that require fundamental innovation or breakthroughs, such as work that Developers do in support of the Product Owner, can now proceed at their own pace without time-boxing work within the Production Episode. The time allotted to Backlog Refinement and Sprint Planning accommodates an unbounded amount of such work without affecting the Production Episode budget or diminishing development time.

The total time per Sprint for Fixed Work, and, further, for each kind of Fixed Work, is nonetheless time boxed. For example, the team may explore alternatives for a high-performance network routing algorithm, and while one can neither time box the overall effort for that particular task nor schedule its completion, it is possible to time-box the work on that effort per Sprint by restricting it to time boxed events.

Additionally, the Product Owner may still fund the team to work on well-contained (i.e., finitely estimable) PBIs within the Sprint, even though they may not contribute directly to the product. If the Product Owner Team lacks the expertise necessary to assess the business consequences of some technology concern (e.g., product performance analysis, prototype construction) then the Product Owner can fund the Development Team to do such analysis work in a Set-Based Design exercise during the Sprint. Such work is limited to activities that can be estimated with low variance by the Development Team or which the Product Owner and Development Team agree should be confined to a fixed, pre-determined time box. For example, if the Product Owner needs a prototyping tool and can use it to create an Enabling Specification that demonstrates what is needed, it is fine to use a PBI to direct the team to do this work. Such a tool feeds the Value Stream and has demonstrable return-on-investment.

However, the Scrum Team should recognize that such work is often waste as it detracts from the Development Team’s focus on the current product increment. This waste that can be avoided if the Product Owner Team instead does such work. The prototype-building tool mentioned above is a good example because it is a one-time cost with ongoing return on that investment. If the Product Owner repeatedly asks the team to actually do the analysis instead of delivering an Enabling Specification, it may point to a lack of expertise on the part of the Product Owner Team and should be raised as an impediment. The variance in this work across Sprints directly creates variance in the Development Team’s work capacity, which makes prediction difficult. In this latter case the Product Owner Team should train or hire team members to fill out the skill set or achieve the right staffing level, to ensure more consistent delivery of Enabling Specifications to the developers.

As an alternative, consider a compromise approach that can manage Developers’ time contribution to analysis (and, by extension, to other activities) as PBIs: Design Sprints as in Set-Based Design.

[1] Steve Johnson. “The Slow Hunch.” In Where Good Ideas Come From. New York: Riverhead Books, 2011, Chapter III.

Picture from: