When talking about blockers on the Scrum board, I realized that we might have interdependent tasks. For example, database design is dependent on some activities in UX flow. Or maybe there is a later realization that one module requires some other module to be finished.

In an ideal case this should not happen, but nothing is ideal. Imagine if during the Sprint developer A is working on Task 1, which is dependent on completion of Task 2. Task 2 is part of the same Sprint. So, in such a case, we basically have reduced the number of parallel tasks in the Sprint.

In such a case, how should we handle Task 1? Should I remove it right away from the Scrum board, and replace it with another task? Or should I just let it be in the Sprint, till the next Sprint starts? What if there is more than one tasks like this in the Sprint?

  • 2
    You need to optimize for meeting your Sprint Goal, not for utilization or parallel work.
    – Todd A. Jacobs
    Commented May 10, 2017 at 22:10

2 Answers 2


I think the question you're asking points more to a problem with how you split your stories/tasks/work items/whatever, and how they're written. Rather than trying to solve the symptoms of this issue, I think it makes more sense for you to try and tackle the root problem here. Of course, there are sometimes technical dependencies between stories.

Writing Work Items

One of the most crucial parts of Scrum is writing user stories that are split vertically, not horizontally. In practice, this means that each user story should cover a full-stack piece of functionality, from Database through UI. Generally, you should avoid writing separate work items for different layers of the application. Having vertically split work items allows you to better estimate how many tasks you can work on in parallel (of course, while respecting your WIP limit) and gives the team a better opportunity to estimate what they can get done.

Splitting Work Items

When splitting up work items in Scrum, Mike Cohn suggests thinking of splitting stories in 5 ways (I've listed them here in my order of preference, rather than the order he lists them in):

  1. Paths -- Consider different paths through the application as split points for your vertical stories (e.g., pay with credit card vs. pay with PayPal.)
  2. Rules -- Split out business rules from one another -- for example, if you're building an ordering system, split "User can make an order" from "User can only order 4 items."
  3. Data -- Split based on the data types you might be receiving or outputting. "User can export data to .xlsx" can be split from "User can export data to .csv".
  4. Interfaces -- Split between the various interfaces you're building for. iOS versus Android, a particularly tricky browser (like IE8 shudder) versus more common browsers, etc.
  5. Spike -- as a last resort, do a research spike to determine how best to split your story.

You'll notice that none of these methods say "separate the database work from the API-layer work from the UI work." Horizontal slicing in Scrum is an anti-pattern, and should be avoided.

Technical Dependencies Between Stories

Avoiding horizontal slicing sounds, based on your original question, like it should help your team solve the problem you're facing. However, every team faces the issue of technical dependencies between stories. "I need to create users before I can update or delete them," for example, if you split out the different CRUD functionalities. In this case, the most effective strategy I've found is simply letting your Product Owner know that there are technical dependencies between different User Stories, and that he or she should prioritize accordingly.

I hope this helps!

  • A follow up question about splitting work items. Items like "Export data to csv" and "export data to xlsx" will have a lot of similarities. Keeping them as different work items can give me a situation where two developers decide to work on these two tasks in same sprint. My goal is to make sure, that only one developer works on one feature. Exporting data in this case, will be a feature. I can expect the developers to be organized enough but I can't guarantee the same if I split the work items like this. Am I thinking too much about the whole "developers will choose wrong items" aspect? Commented May 12, 2017 at 4:23
  • 2
    I think that is more a matter of performing effective Sprint Planning. During the Sprint Planning meeting, engineers should say, "okay folks, we've got .xlsx and .csv export in the same Sprint. Obviously we're gonna reuse some code between these. Mary, why don't you work on .xlsx and .csv in whatever order you want?" Of course, for your team this may just not be an effective way to split items -- it's totally up to you all how you eventually wind up splitting them. If you find that the "Data" method doesn't work, don't use it. Scrum's awesome in that it lets you make it work for your team.
    – JDRoger
    Commented May 12, 2017 at 12:13
  • Okay, so mostly do it based on the situation and after talking with dev. But idea remains the same. Focus on stories not efficiency. Commented May 13, 2017 at 13:12


Your Scrum implementation suffers from a number of framework anti-patterns that are detailed below in the Analysis section. These process issues can generally be resolved through:

  1. Adhering to Sprint Goals.
  2. Allowing the Scrum Team to self-manage dependencies.
  3. Using velocity as a forecasting tool rather a post-hoc measure of effort expended.

The recommended solutions are outlined in detail in the Recommendations section that follows the analysis.


Imagine if during the Sprint developer A is working on Task 1, which is dependent on completion of Task 2. Task 2 is part of the same Sprint. So, in such a case, we basically have reduced the number of parallel tasks in the Sprint...[S]hould I just let it [the task] be in the Sprint, till the next Sprint starts?

Your question, when taken as a whole, exposes a number of framework-implementation smells. These anti-patterns include:

  1. Optimizing for utilization rather than completion of a cohesive Sprint Goal. See also: "the 100% utilization fallacy."
  2. The Scrum Master managing the Sprint Backlog, rather than facilitating team self-organization, swarming, or negotiations with the Product Owner.
  3. Abusing the framework by allowing tasks and stories to be larger than a single Sprint without decomposition, or by carrying work into future Sprints without placing them back onto the Product Backlog at the end of each Sprint for re-estimation and replanning.
  4. Misuse of the velocity metric to measure productivity, rather than as a forecasting tool to determine Sprint capacity.

You may also have Product Backlog Items that don't meet the INVEST criteria.

In any case, by focusing on velocity as a measure of how well the Development Team is doing, you've created an X/Y problem where the team's ability to complete story points by working in parallel has become more important than delivering a cohesive, feature-oriented goal.


Adhere to Sprint Goals

Ensure each Sprint has an overarching Sprint Goal. This is actually a requirement of the framework. The Scrum Guide says:

The Sprint Goal is an objective set for the Sprint that can be met through the implementation of Product Backlog. It provides guidance to the Development Team on why it is building the Increment. It is created during the Sprint Planning meeting. The Sprint Goal gives the Development Team some flexibility regarding the functionality implemented within the Sprint. The selected Product Backlog items deliver one coherent function, which can be the Sprint Goal. The Sprint Goal can be any other coherence that causes the Development Team to work together rather than on separate initiatives.

As the Development Team works, it keeps the Sprint Goal in mind. In order to satisfy the Sprint Goal, it implements the functionality and technology. If the work turns out to be different than the Development Team expected, they collaborate with the Product Owner to negotiate the scope of Sprint Backlog within the Sprint.

A Sprint that meets the Sprint Goal is a success, whether or not all stories and tasks scheduled for the Sprint are completed. Likewise, a Sprint that doesn't meet its Sprint Goal has failed, regardless of whether or not all stories and tasks are completed per the Definition of Done. So, the only real measure of success for a Sprint is the completion of the Sprint Goal; the rest is just advisory metrics.

Allow Team to Self-Manage Dependencies

A Scrum Team should be self-organizing, and the Sprint Planning meeting, the daily standup, and other ad hoc meetings are there to allow the team to manage dependencies! If the Scrum Master is defining dependencies and parceling out work, that's a violation of the core values and principles of Scrum.

Instead, the team should focus on meeting the Sprint Goal. This is often done by limiting work in progress, rather than creating parallel tasks. This helps to ensure that stories are prioritized for the Sprint Goal, and that the whole team works together to get each story to the Definition of Done as quickly as possible. Since a Product Backlog Item (e.g. user story) is either done or not-done, there is no benefit to the team in completing tasks in parallel instead of swarming over stories to get them to Done.

The Scrum Guide also says:

  • No changes are made that would endanger the Sprint Goal;
  • Quality goals do not decrease; and,
  • Scope may be clarified and re-negotiated between the Product Owner and Development Team as more is learned.

So taking tasks or stories out of scope without the approval of the Product Owner is not allowed, but changes that still accomplish the Sprint Goal can be negotiated. If the dependencies can't be finessed within the framework guidelines, then the Product Owner may cancel the Sprint and return the team to Sprint Planning.

Use Velocity and Sprint Planning for Forecasts

Velocity is a measure of team capacity, not productivity. It's generally used to cap the amount of work the Development Team pulls into each Sprint during Sprint Planning. As such, drops in velocity often identify when stories aren't being sufficiently decomposed during planning meetings, when they violate INVEST criteria, or when there are other process problems involved.

As a corollary, a single user story and its component tasks must never be larger than a single Sprint. One reason is that such stories are actually epics that lack sufficient decomposition to be accurately estimated. Another reason is that all work that's incomplete at the end of a Sprint must be placed back on the Product Backlog for prioritization by the Product Owner, and then re-estimated and replanned for a future Sprint (if it remains relevant at all).

The guidance here is to stop focusing on effort expended, and instead focus on features delivered. In agile frameworks, a working increment is the primary measure of success. If you're measuring it in any other way, you're violating core principles of the framework, and may need to re-educate your Scrum Team or senior management on the framework's foundational principles.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

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