TL;DR
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:
- Adhering to Sprint Goals.
- Allowing the Scrum Team to self-manage dependencies.
- 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.
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:
- Optimizing for utilization rather than completion of a cohesive Sprint Goal. See also: "the 100% utilization fallacy."
- The Scrum Master managing the Sprint Backlog, rather than facilitating team self-organization, swarming, or negotiations with the Product Owner.
- 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.
- 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.
Recommendations
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.
