Fixed Work

Mechanics account the time spent tuning a race car engine separately from the estimated race completion time. Engine tuning is routine; race times should get shorter and shorter.

...you are organizing the work that needs to be done to deliver the product, 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 timeline for analysis and the business, and a cyclic Sprint timeline 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ˮ in [1].

✥ ✥ ✥

All work must be accounted for if the Product Owner is to use team velocity (see Notes on 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 toward creating a Refined Product Backlog to pronounce any single Product Backlog Item as being Ready (see Definition of 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 product development work. The Product Owner orders Product Backlog Items (PBIs) in consideration of development estimates and anticipated value. Teams commit to the Sprint Goal, and the Development Team is confident about their estimates. That work takes time. Development Team members are responsible for fitting all work within the bounds of a Production Episode.

Usually, Development Team members can forecast only the development tasks related to their skill set, experience, and area of responsibility—usually, those that involve building the product. 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. 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 may be 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 necessary to support their research. Yet, issues of technology and production often arise as key elements of business risk and, as such, fall within the Product Owner’s purview.

The Product Backlog documents only some of the work that broadly falls under the heading of product development, let alone time that the team spends outside development activities. 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.

Therefore:

Divide all Developer work into that whose duration they estimate (namely, work on the product) and that which they cannot estimate (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 the Development Team does 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 in a Sprint, is nonetheless time-boxed. For example, the team may decide to 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. So all such work may take place within Sprint Planning, which is time-boxed, or within the time-boxed work of an ongoing (across Sprints) Set-Based Design effort.

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 applies to activities that the Development Team can estimate with a reasonably small margin of error, or for which the Product Owner and Development Team together set a pre-determined time box. For example, if the Product Owner needs a prototyping tool and can use it to create an Enabling Specification that helps the team understand what deliverable to build, 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. Having the Product Owner Team instead handle analysis work avoids reducing valuable development time. The prototype-building tool mentioned above is a good example because it is a one-time cost with ongoing return on 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 the team should deal with it 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 the Development Team’s 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 credits: Shutterstock.com.