What is the best way to manage a user story that spans accross sprints? [closed]

Question

We are following Agile SCRUM methodology in the project and we came accross a huge user story that spans accross 2 sprints. How do we report this item in the burn down chart? Which sprint backlog should this user story belong to?

Clan

I don't think they should span sprints, try breaking the tasks down further. – Decapod

Exactly, some tasks under this user story belong to this sprint while the others to the next sprint. But when reporting the progress of the whole user story (specially in the second sprint), how should I go over it? – Clan

Answer 1

User Stories should always be broken down into work items that can fit within the timeframe of the current sprint.

Bring the story to your team and ask them how they would logically break it down to work on it iteratively. Based on that feedback, you can create multiple stories from the original parent story to represent the work and then prioritize/estimate them separately.

In terms of backlogs, you may need to track a Program-level epic backlog with the larger user stories that are being discussed and prioritized with the business stakeholders. If that is the case, you'll have your epics in the Program-level backlog that spans the entire Release. As the stories become more firm and detailed, you can move them into the team's implementation backlog.

I've seen some Product Owners actually maintain a separate excel spreadsheet for the "Business" view of the backlog and just keep their standard backlog for the team with only the broken-down user stories.

Crosseye

Isn't breaking down a US into smaller work items the whole point of creating individual tasks? What if your US contains a dozen tasks that can be completed in any order and aren't dependent on eachother but they can't all be completed in a single sprint? How would you break down the story between iterations? – Crankshaft

My personal approach is that if you can't finish the entire story in the sprint, the story is too big. It is probably a 'feature' or 'epic' or whatever word you want to use for a big piece of functionality.That 'big' story can be made into smaller achievable stories, each with their own set of independent tasks that can ALL be completed in a single iteration. Sometimes this can be done by splitting functionally (e.g. display versus validation of a form), sometimes this can be done by user (e.g. logged in vs. anonymous), or any other means that is logical for the story in question. – Crosseye

Answer 2

The sprint burndown chart indicates how far you are from meeting sprint goal. An uncompleted story will inevitably mean an unfinished burndown curve at the end of the sprint, you don't need to do anything special about it - it's just the state of the iteration.

At the end of a sprint, an unfinished story is typically carried over to the next sprint and thus changes backlog. Depending whether your burndown chart reflects stories or tasks, add up the unfinished story's points, or the unfinished tasks' estimates with the rest of the sprint items to get your Todo total and draw the ideal trend.

You should note though that a story spanning 2 sprints should be accidental and not planned on purpose (split it into smaller stories instead).

Niklaus