Introduction
I may have blogged about this previously. I have written so many blogs, I can't recall any more. However questions regarding Sprint length surface on the forums regularly.
As per usual, the answers one must give always depends on the context and every context is different than the next. So let me start with the context - this is an excerpt of a post on the scrum development group on Yahoo. Incidentally, Yahoo groups is a good place to hang out. You learn a lot from all the questions and the different contexts facing teams around the world.
The Context
A team of 5 members currently working with 10-day sprints. They haven't managed in the previous 5 sprints to have 100% of the User Stories completed. It is typically around 60-70% completeness.
Bookmark/Search this post with:

Nothing can ruin a Sprint Review meeting like having no stories to show the product owner when the sprint is finished. This week, I participated in two Sprint Reviews in two different companies. Both teams had the same problem. They took on stories which were so big that they had a queasy feeling committing to them. Of course, the stories grew during the sprint.
When should you advise your team not to accept a story because it is too big?
3 Warning Signs
Not accepting over sized stories is pretty standard advice. But how do you recognize when the story is too big? These are my warning signs:
- Past performance indicates you won’t get it done
- The story is large compared to the team capacity for the sprint
- The demo is complicated and / or demos many sub components.
Bookmark/Search this post with: