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?
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...
Split your user story in smaller stories which fulfill an enclosed part of your Story. Normally your new stories are more detailed.
e.g. The user needs a report that (report definition) - the user is able to receive the report - the user is able to schedule the report generation / sending...
If one of the new stories is still too large, re-define it till it is small enough and detailed enough to implement it.
That is the normal way of backlog grooming.
