Fixed-Date PBI

(Due Date PBI)

... your Product Backlog tracks the delivery order of value increments to the market. The Product Owner is accountable for value and orders the Product Backlog — not by priority — but to attain the highest overall value (usually long-term value). The team has a reliable understanding of its velocity.

✥       ✥       ✥ 

Sometimes a PBI is blocked by external dependencies. Some things happen on their own time, and the best-laid plans of mice and men often go astray. Some events, developments, and deliveries are beyond the control of the team or the Product Owner. However, in many cases we can still know when those developments and deliveries will take place. You can’t control when an auto manufacturer will start selling a new line of trucks but you usually can trust the manufacturer’s announced availability date. The expected availability date is useful information for planning. It’s good if the Product Owner can order deliveries according to their best fit to the market, and only according to their need to fit the market. However, suppliers tend to work on their own schedules. Some of them aren’t agile and deliver on their own locally optimized schedules or on schedules constrained by parties beyond your control. And most of the time when key personnel have pregnancy or scheduled medical leave, it’s not under the Product Owner’s control or influence.


The Product Owner moves the Product Backlog Item (PBI) blocked by external dependencies (such as deliveries from third-party partner down in the Product Backlog) to a position where it is expected to be ready for selection for a Sprint. The Product Owner marks the PBI with the expected date on which the dependency is expected to be removed. PBIs that are dependent on it should fall below it in the Product Backlog.

As is true with any manipulation of the Product Backlog, the relative position of the PBI should frequently be checked and adjusted as necessary so it lands in the Sprint that will deliver by the target date.

Here is one illustrative anecdote:

A new telecom company appeared in the market. They promised to have the service available within six months; marketing campaigns and sales started. People started subscribing for their services. They needed a good enough call center. Third parties were consulted to provide the call center in time. The solutions available in the market were more than needed and very expensive. The PO decided to build their own call center in house (initial Fixed-Date PBI), but it would be done only after the available 6 months. The decision was to refine the initial PBI so that they can have an initial solution, cheaper and possible with less quality that they will dispose once they have their own solution delivered, after the 6 months.

Here is another:

An international agency’s Scrum Teams required components from its infrastructure team. The infrastructure team’s capacity was insufficient to provide all the required components in time for targeted deliveries. The Scrum Teams collaborated to identify their most important PBIs that could be resourced immediately by the infrastructure team. The Scrums Teams whose PBIs could not be resourced reorganized their Product Backlogs around their Fixed-Date PBIs (PBIs that the infrastructure teams could resource immediately).

✥       ✥       ✥ 

The Fixed Date PBI stands out in the Product Backlog and its visibility enables the Scrum Team to replan.

The Product Owner is better able to forecast deliveries impacted by the Fixed Date PBI. There is less likely to be inventory from prematurely available external components, or partially developed internal components awaiting delivery from an external source.

See Ackoff [1] about the pros and cons of contingency planning as an alternative to forecasts and probability.

See Vacation PBI as a variant on the idea of a Fixed-Date PBI.

[1] Russel L. Ackoff. “Thinking about the future.”, (accessed 2 November 2017).

Image from (under CC0 license).