Agile Stories which are not Unblocked until Middle of Sprint

Question

We are using Agile Two Week Sprints cycles. Sometimes we take on JIRA stories which are blocked, and will not be unblocked until the middle 1 week into of the sprint. Another person's code is complete, and I can finally begin my coding part. Is this an acceptable practice? Sometimes I worry that, I will not complete the JIRA story in time, if time to code, develop, test, deploy is cut in half.

Answer 1

INVEST, Vertical Slicing, and Goal-Oriented Collaboration

Sometimes we take on JIRA stories which are blocked, and will not be unblocked until the middle 1 week into of the sprint. Another person's code is complete, and I can finally begin my coding part.

I think Thomas Owen's answer is a great overall fit, but there's an additional implicit assumption in your question that should be frame-challenged. In any framework, agile or not, work often has dependencies. You're describing a finish-to-start dependency where you can't begin a piece of work until the work product it depends on is completed. Dependencies are sometimes unavoidable, but if you are regularly planning work that is highly interdependent and lacks sufficient slack to be completed reliably then you have a process problem.

While not required by the Scrum framework, the INVEST mnemonic is widely considered a best practice, and it sounds like you're routinely planning items that are not independent, and may not be small enough to be estimable with high confidence when started so late in the Sprint.

"Vertical slicing" of backlog items is also a common best practice. Rather than passing work along a conveyer-belt style production line, Scrum practices that advocate a more holistic whole team approach where the Developers collaborate on shepherding an Increment through the process is generally preferable. You may hear this referred to as "swarming," "pairing," "mob programming," or other terms depending on your given product domain, but it all starts with understanding that a completed Increment is something the whole team is collectively focused on delivering, rather than relying on input/output queues between Developer workstations.

Since you didn't provide any specifics about your work items, consider this example. Rather than having one developer work on a back-end model data before another developer starts work on the front-end user interface, imagine a user story that says:

As a web site user
I want to access my account information from the navigation bar
so that it's easy to change without having to drill down through menus.

This is a great vertical slice because it requires work on multiple layers of a web application, and ideally can be a collaborate task that involves design and testing of the database, model, controller, and view all at once. Instead of a stove-piped process, members of the team can:

1. swarm over this work to write test-first validations for the Definition of Done;
2. let the tests drive emergent design;
3. work interactively on the implementation of the user interface, letting the iteratively evolving UI drive the model and controller changes;
4. refactoring as you go, iteratively improving both the design and implementation;
5. calling it "good enough" when all the tests pass and the Increment meets the Definition of Done.

If the whole Scrum Team is following the requirements of the Scrum Guide, then the entire team has committed to a singular Sprint Goal rather than to doing a random collection of individual work items. The Scrum Guide section on the Sprint Backlog specifically says:

The Sprint Goal is the single objective for the Sprint. Although the Sprint Goal is a commitment by the Developers, it provides flexibility in terms of the exact work needed to achieve it. The Sprint Goal also creates coherence and focus, encouraging the Scrum Team to work together rather than on separate initiatives.

Note the emphasis on a single, focused objective. Scrum doesn't promote individual Developers working on unrelated or sequential tasks in parallel; it actually requires them to collectively commit to delivering a coherent Increment of value: the Sprint Goal. The Sprint Goal in turn creates progress towards a Product Goal. If you aren't planning your work around a focused goal, and then layering on tightly-coupled dependencies that can't be delivered independently, then you are actively creating the pull-queue problem you're describing in your original question.

Don't do that. Instead, work on planning your work around Sprint Goals and collective delivery of each Increment. These changes should reduce cycle delays, increase the success rate of goal-oriented deliveries, and decrease the risk of incomplete work due to unforeseen delays or queuing issues.

Answer 2

In Scrum, a Sprint is not about completing work. The primary purpose of a Sprint is to achieve a valuable goal. Some work is needed to complete the goal. However, we want to acknowledge that at any point in time, the work is only a guess as to what will be needed to accomplish the goal. By doing the work, additional needed work may emerge, and some work may become unnecessary.

In this goal-based approach, the first question is whether the team believes this work is necessary to accomplish the Sprint Goal. If the work is believed to be necessary to achieve the goal, then there's some risk in committing to a goal where you won't be able to start the work until the middle of the Sprint, and there may be delays beyond that. There is some level of risk that may prevent the team from achieving the goal. Some contexts favor consistency and predictability, where the goal should be highly achievable. Other contexts may give the team more freedom and flexibility to commit to lofty goals and fail to achieve them without impact. Only the team can make the decision that's right for their context.

If the work isn't necessary for the Sprint Goal, it likely doesn't matter. There are a few ways of thinking about planning unneeded work. At Sprint Planning, some teams only pull in work they believe is directly associated with the Sprint Goal. If they achieve the Sprint Goal and can take on additional work, there's a well-refined Product Backlog to choose from. Other teams pull in work up to their capacity so that there's a clear identification of what the team may work on once the Sprint Goal has been achieved. Both approaches are equally valid for the team.

Answer 3

Is this an acceptable practice?

Well, Scrum is about cooperation, so I guess it is acceptable, if you think it is acceptable and accept it.

I would argue that according to Scrum, you as the development team should have sole command over how and when certain stories are worked on in the sprint. And if you cannot work on a story when you want to, maybe even the minute after sprint start, it is not fit for this sprint. Wait until it is unblocked, then put it in the next sprint.

Personally, we have always had Product Owners trying to sneak it by, promising that it will be available at date X... only to not be available, late, not according to the specs etc. So every time we came to the conclusion that "really, trust me, it will be ready, truly, pinky promise, I swear" is not good enough. Either it's ready for development when the sprint starts, or it is not.

Answer 4

If a story is not clear, you can not give story points to it. If you can not give story points to it, you can not take it into the sprint. So, if the blocking is because of uncertainty, you can not take it into the sprint.

If a story depends on another story to be completed, first, the other story should be completed in a sprint and after its completion, you can take the dependent story in the next available sprint.