0

Sometimes, when sizing user stories, the team says "but in order to do this, we need to ask this guy, and we don't know how long it will take for them to answer", or "we need to raise a ticket to (A) and (B), after we have done this, and then wait for them to proceed, in order to complete our job". I am talking about dependencies, sometimes in the form of communication, some others in the form of an action from an external team.

I know that a user story should be INVEST, in this case, independent. What is your suggestion to such user stories though? Should we define in the DoD that if it has dependencies, then we try to break them first, and then size it? Or sizer it, factoring in the external dependencies / impediments?

  • When you say "sizing" you mean the effect on the US estimation, or how big the scope of the US should be considering external inputs? – Leonardo Pires Jan 23 '18 at 16:54
  • When sizing we want to estimate the total effort to complete a user story. – dqm Feb 1 '18 at 7:32
3

My preference with stories that have an external dependency is to say that the story will not be taken into a sprint until the dependency is resolved. This is not always possible, but where possible it is worth doing, even if it feels like an unnecessary delay.

If it is not possible to resolve the external dependency prior to starting the sprint then I often recommend the team increases their sizing estimates to allow for the impact of dealing with the dependency. For example, a story that would normally have been a 3 pointer, now becomes an 8 pointer as the team needs to facilitate and coordinate an external dependency delivery.

The long-term goal should be to eliminate this kind of story. A good way to do this is to discuss any stories with external dependencies at planning and at retrospectives and see if there is an adaption possible. For example:

  • Perhaps there is a skill set the team lacks? Could there be some training or a change in the membership of the team so that there is no longer a need to rely on external assistance?
  • Is there a technical approach that avoids the dependency? Perhaps mocking a particular service means we don't need to coordinate with the team that provides that service?
  • Possibly there is a permissions problem that stops the team doing all of the story themselves? Maybe it is worth bringing together all the parties concerned and trying to find a way that avoids waiting for a ticket to be actioned?
1

TL;DR

Scrum doesn't require user stories, and since the Product Backlog is intrinsically ordered, 100% independence between items is not required. However, the underlying issue of how to estimate external dependencies is a valid one that is easier to resolve once you focus on level-of-effort rather than elapsed time.

The Definition of Done is not the same as your team's working agreement. It is how you know stories are complete. Regardless of how you handle external dependencies, it is more of a framework estimation/planning issue than a done/not-done issue.

Estimate only the level of effort required within the team to manage the external dependency. Everything else is a process issue, and will be covered below.

Scrum Doesn't Mandate User Stories or Complete PBI Independence

Tasks Needn't Be Stories

Scrum doesn't mandate use of the user story format. The Scrum Guide mentiones Product Backlog item(s) 25 times, but "user story" is not mentioned even once.

Even if the Scrum Team adopts the user story format for its Product Backlog, Sprint Backlog items don't have to be in the same format. In fact, most tasks on the Sprint Backlog should be decomposed from a related Product Backlog Item, and trying to coerce each task into a user story instead of a bullet point or checklist item may be overkill.

Independence

While user stories should be as independent as possible, the "independent" INVEST mnemonic is a best practice for the user story format rather than a specific framework requirement of Scrum. In a Scrum context, the goal of story independence is to maximize the ability of the Product Owner to reprioritize Product Backlog Items (PBIs), and to optimize the Development Team's ability to meet the Sprint Goal even if some items from the Sprint Backlog (SBIs or tasks) are blocked or incomplete.

In real-world Scrum implementations, tasks on the Sprint Backlog will often have dependencies and sequencing requirements. More specifically, reducing the dependencies between PBIs doesn't necessarily reduce dependencies within a user story. Furthermore, Scrum requires some level of central coherence, which is why the framework doesn't mandate a backlog free of all story dependencies. Scrum is, in part, the art of finding the right level of coupling between backlog items to create a coherent Sprint Goal while still allowing the backlog to be reordered between Sprints to adapt to changing requirements.

Handling Wait Tasks

An important aspect of story points, and of Scrum estimation in general, is that the primary metric is effort, not time. Therefore, I always coach that wait tasks (or stories that contain wait tasks) discount externalities outside the team provided the dependency will fit within a single iteration.

As a practical example, let's consider this user story about embiggening a widget taken from the Product Backlog:

As a widget consumer
I want an embiggened widget two orders of magnitude larger
so that I can more easily frobnicate the whatchamacallit.

When the Development Team selects this user story during Sprint Planning, the embiggening story is decomposed and the team does "just enough" planning to ensure the story is likely to fit within the current Sprint, and to add key tasks and dependencies to the Sprint Backlog. This story's tasks include:

  1. Ask Bob in Procurement to order a baker's dozen of standard widgets.
  2. Borrow a widget stretcher from Sally in Supply.
  3. Stretch the widget.
  4. Insert the newly-stretched widget in the whatchamacallit.
  5. Run the frobnication regression tests.

While the procurement process and the supply requisition are prerequisites for completing the story, the effort required for those tasks is essentially that of making a request. This likely a phone call or a bit of paperwork, and possibly a follow-up or two. Even though the Scrum Team should make those external dependencies visible, and the Development Team should track them within the Sprint, the Development Team's internal level of effort for those tasks is minimal.

Even if a team member must chase after Bob and Sally for days or weeks, the story should be estimating team effort, not time elapsed. If the story would be estimated at three points if the materials were on-hand, having to call or email someone outside the team to order equipment doesn't really add a measurable level of effort within the team, and is therefore a probably still a 3-point story. On the other hand, if someone on the team must prepare a 24-page business case before Bob or Sally will agree to make the necessary equipment available for the team, then that level of effort might turn a 3-point story into an 8- or 13-point story to reflect that the effort is internal to the team.

When to Isolate External Dependencies

In general, external dependencies can be written as low-effort tasks, and don't change estimates much. However, when the internal level of effort is large, or when the team isn't confident that an external dependency will fit within a single iteration, then the stories/tasks should be split and made as independent as possible. For example, the Scrum Team might develop a new user story for the Product Backlog that should be done a Sprint or two ahead of the embiggening story:

As a Development Team member,
I need to requisition a widget stretcher from Sally
so that we can embiggen a frobnicating widget in the whatchamacallit.

While the stories are related, this story can be delivered independently of the embiggening story. If they can be consolidated, great! But if not, isolating the requisition from the embiggening reduces uncertainty and makes it easier for the team to forecast when the work will be done.

Recommendations

Considering all the foregoing, I recommend the following:

  1. Estimate only the level of effort required by the Scrum Team.
  2. The expected time to complete an external task is only relevant if it puts the Sprint Goal at risk, or if the externality is likely to cross Sprint boundaries.
  3. Split all stories and tasks that will cross Sprint boundaries.
  4. Split off all stories and tasks that are "known unknowns" so that unavoidable dependencies can be re-evaluated at Sprint boundaries.

Should a Sprint Goal be unavoidably reliant on an external dependency, then that should be a visible risk for the Sprint. Scrum doesn't guarantee success of the Sprint; it simply makes the process and its artifacts transparent!

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.