In Scrum, how do you account for tasks with lead time?

TL;DR

In the context of "INVEST," independent doesn't mean there are no prerequisites or dependent activities. Rather, it means that a given unit of work can be estimated, performed, and tested as a unit within a single iterative cycle (e.g. one Sprint).

It often helps to break up time-spanning items into smaller activities that can function as prerequisites, while still being performed separately from dependent backlog items. This will allow Product Backlog items to meet INVEST criteria even when the dependent features (think epics or themes) might take several Sprints to complete.

Decompose Work Into "Sow" and "Reap" Activities

Some tasks involve a small amount of time from a team member, let's say 1 story point, but the definition of done for that story involves ordering parts that have a certain lead time that might span one or two sprints.

The best way that I've found to handle low-effort but time-spanning tasks is to decompose them into discrete actions. In farming, "planting" and "harvesting" are part of a long-term cycle, but can be represented as separate activities.

Using your own example of ordering parts, there's an external dependency on the ordering process and the vendor. You might split the story into multiple low-effort items that don't all have to performed within the same time box.

1. Place order for widgets needed for a future story.

   As a team member,
   we need to order a box of widgets
   so that we can integrate a widget into our thingamajig.

2. Follow up on widget order if not received before starting the dependent user story.

   As a team member,
   we need to get tracking information on our widget order
   so we'll know when our widget-integration story is ready for Sprint Planning.

3. Unpack & verify widget.

   As a team member, we need to get the box of widgets from the mail room &
   verify the contents
   so that we'll know we have the widgets on hand for integration.

4. Plug widget in.

   As a widgetologist,
   I want a widget integrated into my thingamajig
   so I can frobnosticate the embiggener.

As a practical matter, you might order the widget in the current Sprint. During Backlog Refinement or Sprint Planning, the Scrum Team would then pull in the appropriate follow-up stories as needed. During planning events, the team would also consider whether all of the prerequisites needed for the widget-integration story (such as having the needed widgets on hand) have been satisfied.

Some of the follow-on stories are obviously be dependent on having already ordered the widgets, or already having received the ordered widgets. Nevertheless, getting tracking information or unpacking/verification would be prerequisites to stories that assume the presence of the widget, and these stories could be pulled into a Sprint or removed from the backlogs as necessary. For example, since unpacking and verification of the order can be performed independently of using a widget, the story meets INVEST criteria.

This general pattern of treating an initiating activity and a closing activity is widely applicable to a variety of time-spanning dependencies. It seems to address your given use case, and the pattern is widely applicable to many types of stories that would otherwise violate core principles by spanning multiple Sprints.

Simple answer is implement a DOR(Definition of Readiness).

DOD is the exit criteria for a task to exit/burn from the sprint.

DOR is the entry criteria for a task to enter/eligible for a sprint.

One of the DOR entries could be this case external dependecies to be resolved before it comes to the sprint backlog. If you have a task that is not burnable during a sprint because of an extrenal dependency which be blocker for the team. If that is blocker as the SM it will become your problem. So identity the problems/blockers/dependencies early on an solve them for the team.

Implement this part of the process to solve the blockers not reactively but proactively.

I'd make the lead time requirement a story in its own right with a reminder that this needs to be done in, say, (n) sprints ahead (n giving you enough time + buffer to get the order delivered) of the development story. Although not a real story, I do this with other systemic constraints in projects all the time. If the story card is clear enough it just won't get lost.

In the ideal world, you'd work with your supplier to help them become more Agile so that they could fulfil your requests more quickly.

In the real world, pragmatism rules. We normally identify elements with long lead-time - usually computers and servers for testing, in our case - and get those elements in place. It can help to have visibility of the full, high-level backlog so that the team can identify these elements more easily. You can do this by listing the business outcomes and user / system capabilities that need to be achieved.

If you're using a tool which only covers discrete concerns, add a small story to remind yourself about the lead times.

Don't order the items too far in advance, though. Real Options may be helpful in working out when the last responsible moment is, and how you can pay to keep options open if appropriate.

At the end of the day, most useful Agile practices are based on extreme forms of common sense. We can still use the less extreme forms where applicable.