Handling External Factors in Scrum

A common issue that comes up in product development is how to handle external dependencies. For instance, an engineer is working on legacy code and needs to setup their work-space in a specific manner before they can even start working on their user story. Should we create a task in the story and increase the story points? Just handle it off the record and call it a day? Do we add a separate story to our product backlog? Let’s take a step back and examine our options.

With Me or Against Me

Our first idea was to add a task in the story and increase the point value. There’s a couple of issues with this strategy:

1. The supporting task shouldn’t affect the story’s point value when it isn’t part of the delivery.

2. It may be related to other stories. If multiple stories are dependent on this supporting task, then we should create a separate story linked to the dependents.

We can think of the task as either a deliverable or an impediment. In our case it would be considered an impediment to progress — we aren’t delivering our work-space to the user. It’s important to make impediments visible so we know how they are affecting our progress. If we know about impediments, we can plan for them ahead of time and reduce crunch time scenarios.

Obscurity Causes Complexity

The second option was to handle the impediment without tracking it. This is not a great strategy as obscurity leads to complexity and inconsistent velocity. If we don’t track our tasks, how do we know what was done?

The main cause of complexity in software is obscurity — information that is not obvious. This applies to product development as well. If we can’t see where our time is going, it makes it tremendously difficult to plan ahead. ALL work should be visible and tracked in some manner.

Increasing Visibility

This leads us to our final option, creating a separate user story and adding it to the product backlog. By isolating the task, we have decoupled it from the story. This allows us to track it independently in our backlog. In our case this makes the most sense as it provides a high level of visibility since everyone on the team will be looking at the backlog.

Visibility is a key factor to successful teams and organizations. Being able to see what each team or member is working on increases cohesion and sense of purpose. As an engineer if I know that what I’m doing has saved someone time or moved us towards our goals, then it makes me feel great and want to continue contributing.

What gets measured gets done — start tracking your externalities!

Related posts:

Nothing like having a ton of creativity whirling about in one's head and feeling that it is stuck.

Sometimes we need to hide certain columns from models without removing it from table. Suppose you need to maintain backward compatibility and do not actually want to remove certain columns but it may…

The stock market has been on collision course in recent weeks due mainly to the global spread of coronavirus (COVID-19). Accordingly, we aligned our portfolio to help us weather this extreme period…