3

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.

Improve this question
1
  • There are some good answers below, but you're asking a very vague question so you're getting vague answers. If those don't answer your question for you, can I suggest you provide an example? It may help us give more specific answers.
    – Daniel
    Feb 15, 2020 at 17:04

2 Answers 2

Reset to default
3

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!
Improve this 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.

Improve this answer
3
  • Where does a spike exist in relation to a sprint? Would a spike be considered a product backlog item? Would that be classified as a task?
    – Mark Saluta
    Feb 17, 2020 at 13:44
  • @MarkSaluta, a spike is a product backlog item with a fixed duration and with the aim of gaining knowledge so that the uncertainty in another backlog item can be reduced. It would be on the same classification level as a user story.
    – Bart van Ingen Schenau
    Feb 17, 2020 at 13:53
  • As Bart says, it is often added to the product backlog as a fixed-length item. You could classify it as a task if you wanted to, or create a custom category for it. Some teams prefer not to add it to their backlog and instead treat it as a reduction in capacity. They may something like: "Our usual capacity is 20 story points, but as we are doing a spike this sprint, let's reduce it to 17 story points".
    – Barnaby Golden
    Feb 17, 2020 at 14:02

Your Answer

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

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