3

During a sprint in scrum, the scope of the sprint should not change. However, I often find that after the sprint starts and I begin working on a story, I discover new stories that must be done. For example, I encounter a bug in the code.

In this case, I usually create a new bug issue and start working on that as it's blocking my main story. However, this expands the scope of the sprint.

I also sometimes find that when I start working on story, I break the story down into smaller parts, create stories for each of these. Then I link these stories to the original story. However, this again expands the scope of the sprint, and also it sometimes duplicates some of the story points, because some work is accounted for in the smaller stories which are related to the bigger story.

Therefore, my question is how do I account for new work that I discover while working on stories in scrum without affecting the scope of the sprint? Or is it acceptable to expand the scope of the sprint in this case?

I don't usually add the new work items to the backlog because they often block the main story I'm working on, so I just start implementing them straight away.

Improve this question

4 Answers 4

Reset to default
3

Discovery is a natural part of the software development process. It can be disconcerting when stories end up being more involved than you expected, but it is not something you should be concerned about unless it is happing all the time.

Reserve some capacity in your sprints for discovery. Mike Cohn talks about the importance of leaving space for unplanned work.

However, you wouldn't expect every story to grow in size. If that is happening it may be worth considering doing the following:

  • Reduce the size of your stories, so that there is less room for uncertainty
  • Spend a little more time on backlog refinement
  • Consider using spikes to collapse unknowns
Improve this answer
2
  • 1
    When I was doing traditional project management and could plan and track time, the ratio of planned to unplanned Work was 2 to 1. Probably partly because I was in experienced at the planning part, but having headroom for the unexpected is good practice.
    – Peter K.
    Dec 17, 2017 at 21:52
  • @siamii - I think Barnaby has the right answer, definitely put some emphasis on his third point, "perform technical spikes." These are light-weight experiments that test different paths and solutions to technical problems, ahead of actually starting the work. Often on my teams, we have spikes 1-2 sprints out from doing the work for highly technical or complex features
    – Jon Luzader
    Dec 19, 2017 at 18:09
0

Problem

You aren't properly differentiating between stories (or, more canonically, Product Backlog Items), tasks, and chores. You are also failing to differentiate between bugs, defects, and incomplete work.

Each of these things gets handled slightly differently, and not all of them actually belong within the current scope. In short, your problem is that you haven't correctly defined the goal of Sprint, the scope of the story you're working on, or the Definition of Done.

Solutions

The team needs to do a better job of scoping and planning the work during Sprint Planning. If you're regularly finding unexpected work of significant scope during each iteration, then the team is not spending enough time thinking through the level of effort and developing the work breakdowns for the Sprint Backlog during the Sprint Planning exercise.

Because iterative methodologies often leverage emergent design, a certain amount of refactoring, rework, and unplanned tasks are not unexpected. In fact, they should inform your level-of-effort planning throughout the process. This includes selecting PBIs, decomposing stories into tasks for the Sprint Backlog, and estimating available capacity for the current Sprint.

Finally, triage the problems properly. In practical terms, that means:

  1. Stories that have been improperly scoped or planned should be reviewed against the Sprint Goal to see if an Early Termination is called for.
  2. If new tasks are required, they should go on the Sprint Backlog and discussed as a potential blocker or dependency during the daily standup.
  3. If new stories are uncovered, they should go onto the Product Backlog for a future Sprint. If they are blockers, see #1 & #2.
  4. If in-Sprint defects are uncovered, see #1 & #2.
  5. If defects or bugs from a previous Sprint are uncovered, that was a failure of the Definition of Done. Bring it up to the Product Owner and review the DoD with the team. Then follow steps 1-3.
  6. Anything else that's new work goes onto the Product Backlog.
  7. Anything essential for the current Sprint Goal should be a task on the Sprint Backlog, not a story. If the task puts your Sprint Goal in jeopardy: go to #1, do not pass GO, and do not collect $200.
  8. Ask your teammates, your Scrum Master, and your Product Owner for advice.

Scrum and iterative methodologies in general rely heavily on time boxing and careful scoping. If you aren't doing enough scoping work during Sprint Planning, and if the team isn't rigorous about managing the work within the time box, then that's an implementation failure that will eventually derail the project.

It's not that surprises aren't routinely uncovered in Scrum; they are, and the framework allows for that. It's just that treating all work as in-scope for the current iteration is a fundamental no-no for effective Scrum.

See Also

Improve this answer
0

There are three reasons your sprint estimate might turn out to be wrong. ie you dont finish everything you planned to do in the sprint.

  1. Your estimate was wrong.

This is normal. just adjust the expected velocity accordingly and it should work out over time.

  1. You increased the scope of the sprint. ie. you added more features during the sprint.

This should be avoided. Don't fix that unrelated bug, don't add that extra polish etc.

  1. You increase the estimate during the sprint.

It sounds like this is the one you are doing. You add more detail to your existing scope but the estimates for the detail all up to more than the original estimate.

My advice is to either do the break down in sprint planning, so that you get the higher estimate before starting. Or, if that is not possible don't use the increased estimate in your planning, stick with the original and treat it as an incorrect estimate.

Depending on your tools, this could be done by simply putting 0 hours against sub tasks, or configuring the burn down to just look at stories or certain types of task.

Improve this answer
0

Please read The Scrum Guide. The Sprint Goal as an objective is the key. If it becomes obsolete then the Sprint should be canceled. Details will emerge during the Sprint as the effort and learning are ongoing. The Sprint Backlog is a forecast of what will be delivered.

Scope may be clarified and re-negotiated between the Product Owner and Development Team as more is learned.

Improve this answer
0

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.