Take the 2-minute tour ×
Programmers Stack Exchange is a question and answer site for professional programmers interested in conceptual questions about software development. It's 100% free, no registration required.

Possible Duplicate:
Scrum: how to handle backlog-items that are longer than one sprint

I have a project with complex user stories which take way longer to implement than spring length.

For example: user story sounds like this :

"User is able to receive a report at 10:00 am daily"

But behind the scenes, it requires around 2.5 month of development so it does not fit in our two weeks sprints.

Could you share the best practices for this case?

share|improve this question

migrated from stackoverflow.com Jan 13 '12 at 22:15

This question came from our site for professional and enthusiast programmers.

marked as duplicate by Matthieu, Yannis Rizos, Dan McGrath, ChrisF Jan 15 '12 at 13:23

This question has been asked before and already has an answer. If those answers do not fully address your question, please ask a new question.

2 Answers 2

Split your Userstory in smaller stories which fullfill an enclosed part of your Story. Normaly your new stories are more detailed.

e.g. The user needs a report that (report definition) - the user is able to resieve the report - the user is able to schedule the report generation / sending...

If one of the new stories is still to large redefine it till it is small enough and detailed enough to implement it.

That is the normal way of backlog grooming.

share|improve this answer
up vote 6 down vote accepted

Create an epic, see: http://scrummethodology.com/scrum-epics/

In Scrum, the teams that complete the work assign effort estimates to every user story. Of course, that assumes that a team can reach a consensus for an appropriate estimate. What happens when a story includes too many unknowns to tell just how big it is? Or what if the story’s requirements are known, but its effort is too huge to complete in a single sprint? We call these stories “epics.” While a team should be able to tackle a typical story in four to sixteen hours, an epic is a story that would require twelve or many more to complete. Most Scrum experts suggest that any task requiring twelve or more hours should be decomposed into several smaller tasks. These stories will not only be smaller in scope, but also more narrowly defined. Basically, breaking down epics helps the development team translate its work into chunks that can be accomplished in a single day.

Is there any danger to estimating an epic? Quite simply, the answer is yes. Estimating epics can be harmful because it creates a false sense of certainty for the Product Owner...

share|improve this answer