Strategies For Reducing Black Hole User Stories

Question

We have several user stories that have spilled over into multiple sprints. Some of them are fairly large and complex, requiring very high level of understanding of a) what we want, and b) the granular steps on how to arrive there.

The team has given them higher point levels, but haven't been able to really allot any hours, given the unknowns.

I've reviewed the user stories and could possibly slice them somewhat, but some of them really are just huge black holes.

What strategies as the Scrum Master can I implement to assist the team with being able to dissect these stories to reveal its done-able parts?

EDIT:

As an example, I have a user story that reads mostly as follows:

"As a user, I would like to upgrade to the latest CentOS7 version of Linux, so that I can ensure the security of my IT infrastructure by only running supported versions."

We have fairly complex home-grown software running on the current OS. The upgrade of the OS is multifaceted in that it needs to meet specific security standards, apply patch updates, regression tests to ensure that the software works as intended on a completely new operating system. Each of those, and there are likely many more high-level tasks, are going to require quite a few additional sub-tasks.

Another one (definitely breaks some basic Scrum rules):

As a Software Developer (I know...), I want to implement the rules engine logic discussed in user story 123456

The rule engine has approximately 15 bullet points as high level logic requirements, each with its own inherent requirements in order to make them work.

My initial thought would be, since the requirements are somewhat defined, to separate the units of work that are independent, small enough to easily fit into a sprint, and estimable.

Answer 1

How Does One End Up with Big Balls of Mud?

The "big ball of mud" problem is usually caused by a combination of one or more of the following:

• Scoping issues.
• An excessively-large cone of uncertainty.
• A lack of validated learning within the iterative process.
• Excessive coupling of deliverables.
• Insufficient granularity.
• Missing tests needed to feed design.

and other common anti-patterns. I will highlight three common approaches to making your ball of mud more manageable.

Respect the Time Box

Firstly, backlog items should never automatically carry over from Sprint to Sprint. Incomplete work items should always be returned to the Product Backlog to be re-prioritized, re-estimated, and (when necessary) re-worked.

Re-Evaluate the Value and Design of This Story

Secondly, if this incomplete story isn't putting your Sprint Goal at risk or preventing the team from achieving the goal, it's worth questioning:

1. The value of a backlog item that isn't tied to the Sprint Goal.
2. Whether your overall process is delivering value if Sprint Goals are being continually missed.

The answers to these questions will help you determine how important it actually is to fix this story, or whether you need to fix your process instead.

Adjust Your Estimation and Planning Processes

Thirdly, after reviewing your process and this particular story within your Sprint Retrospective, consider:

1. Whether you can discard this story altogether.
2. Whether this story can be rewritten to meet INVEST criteria.
3. Whether this story (or its decomposed replacements) should be re-prioritized so that it can be pulled into a Sprint where it's actually relevant to the Sprint Goal.
4. Whether you need to design some story spikes to reduce the cone of uncertainty around the planning or implementation of this story.
5. How to fix your planning process to better respect the boundaries of the time box each Sprint.
6. How to select Product Backlog Items that align with a cohesive Sprint Goal each Sprint.
7. Whether your stories are being designed around a test-first approach to the Definition of Done. If not, feed that fact back into your planning process too!

Answer 2

A useful technique is spikes.

When the team has uncertainty about a particular user story or if they think it may be complicated then they can use a time-boxed investigation to reduce the risk and to make it easier to estimate.

The time-boxing is important. We don't want to simply launch into an open-ended investigation. The aim of a spike is not to solve the problem. Instead we want to do just enough investigation to collapse a few unknowns.

The only issue with spikes is one of timing. If a complex user story is urgent then waiting a sprint for a spike to take place may be problematic. The best way to avoid this problem is to carefully review your backlog and anticipate the need for spikes in advance.