3

We are using the Rally tool for managing our sprints. Mid-way through one of the sprints, the Product Owner de-scoped two user stories. These two stories are complex user stories carrying 8 story points each. Almost 80% of effort was already spent on these user stories. So, the team stopped working on these two user stories. I have couple of questions.

  1. How should the burn-down chart be represented because the user stories carrying bulk of the size for this sprint was de-scoped. As a scrum master do I need reset the Y-axis in the burn-down chart with the story points that are still in scope? If I don’t reset the Y-axis the burn-down chart may present a wrong picture to management that as a team we could not deliver what was committed

  2. In our estimation meeting for the release we projected X story points for the release. Now, what we will be delivering X-16 story points as we de-scoped two user stories. By the release date, if these situations continue to arise we will be delivering far less story points than what we committed for the release. What this mean is that the cost we incur will not reduce if we deliver fewer story points. As a Scrum Master, how do I neutralize the cost vs. story points delivery?

  3. How does the team book the timesheet for the work? The team did 80% of the work, but the user story itself was not completed. Do I need to mark the user story as completed and ask the team to fill the hours?

Improve this question
2
  • 1
    You're trying to justify some sort of cost per story point. That's not how Scrum works. This is a bit of an X/Y problem; I tried to address it below. You may also want to consider breaking out some of your sub-questions into separate questions, as they aren't directly related to scope per se.
    – Todd A. Jacobs ♦
    Mar 6, 2013 at 14:02
  • This raises very important and useful questions, and I second CG: Breaking it down into separated questions could give you better insights on each question.
    – Tiago Cardoso ♦
    Jan 6, 2015 at 19:18

2 Answers 2

Reset to default
4

Strictly speaking, the PO shouldn't be changing stories in the current sprint. For Scrum, best practice would be to abandon the entire sprint and start over with a new sprint planning session, new burndown etc.

Other stories currently in progress can still be brought into the new sprint of course.

As for timesheets - you should probably ask whoever consumes the timesheet info what they would like done. At my place we'd still mark it as time spent working on that product/project.

Improve this answer
2
  • Thanks Ben. I have a follow up question on timesheets. My worry is if the team spent 80% on a story and it is abandoned, we are booking the time, but as we know the story itself was not complete - so we are calculating velocity based on comleted stories which is far less than the estimated velocity in this case. So, our projection for the release based on the average velocity may take a beating, especially if similar type situation repeats multiple times. So, i was wondering how to handle this. LEt me know if my question is not clear
    – ramu
    Mar 8, 2013 at 8:53
  • Ahh... our timesheets are just used for finance purposes not for velocity calculations. You're right, you shouldn't be including incomplete stories in your velocity. While velocity will take a dip now, if you've done most of the work on them, you'll probably pick them up in a sprint soon and need to do less work to get the points meaning your velocity will average out over time.
    – Ben
    Mar 8, 2013 at 10:17
3

TL; DR

The Sprint Goal must not be changed during an iteration. Changes that would prevent the Scrum Team from reaching the Sprint Goal must terminate the sprint. The rest is just an accounting exercise that helps the organization understand the cost to the project for scope changes made mid-iteration.

When Scope Changes Mid-Sprint

Scope changes really require a conversation between the development team and the Product Owner, mediated by the Scrum Master. Scrum is designed such that scope changes should be made during the inspect-and-adapt inflection points at the start/end of every iteration, rather than mid-sprint. However, Scrum provides several mechanisms for managing just this sort of issue.

While it is certainly possible for the development team and the Product Owner to cooperatively modify stories—so long as the modifications don't prevent the Scrum Team from meeting the defined Sprint Goal for the iteration—stories can't just disappear from the sprint. They must be accounted for, as scope change must always remain visible and transparent to the entire organization.

Here is the typical decision tree for how to handle removal of stories from a sprint:

  1. The development team and the Product Owner may agree that the story can be incomplete without compromising the Sprint Goal.

    • If the story is already completed, then the story is "done" and counted in the velocity, whether or not the feature is used. This will correctly reflect the work completed within the sprint.

    • If the story is not 100% complete in accordance with the "definition of done," the story is simply "not done" and no story points are awarded in the burn-down. This will correctly be a drag on velocity because it represents resources taken away from other stories.

  2. The Scrum Team may determine that the user story is essential to the Sprint Goal, which requires the Product Owner to call an Early Termination to the iteration and a return to Sprint Planning.

    • Early Termination makes it explicit that the scope has changed radically enough to invalidate the plan for the current sprint.
    • Early Termination correctly adds visible overhead to the overall project. Dramatic scope change isn't free; that's why the process makes the cost of interrupting an explicit cost for which the Product Owner is responsible.
    • You can often skip the Sprint Review with an Early Termination, but don't skip the Sprint Retrospective or Backlog Grooming before returning to Sprint Planning.
    • Only stories that are complete per the "definition of done" will be counted in the aborted sprint's burn-down. Because the sprint is a non-standard length, this may be a blip in your data, but it still accurately reflects the amount of work completed in the iteration. This is why velocity should be calculated as range based on trailing averages; it acts as a smoothing function that embraces even dramatic scope changes in the metric.

Educate About Change Control

Agile frameworks embrace change. That doesn't mean change is free. As long as you use the framework properly, change will be controlled, which is generally a key objective for any project management framework. As the Scrum Master, it's your job to educate the organization about how to use the framework to its best advantage. Hopefully, this answer will help with that.

Improve this answer

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

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