4

Is it generally a good practice to have large story-points for user stories in a sprint? We are following a modified Fibonacci series of 1, 2, 3, 5, 8, 13, 20, 40, 100. We estimate the effort considering only the complexity involved, and it's all relative. So, would it be okay to have effort estimates larger than 20, or is it recommended to have less than that?

3

All Accepted Stories Must Fit in a Single Sprint

Your velocity is a range that represents the team's capacity for each iteration. If your team velocity is 40-50 story points per sprint, then you could:

  • Accept five or six 8-point stories.
  • Accept two 20-point stories.
  • Accept one 40-point story.

The idea here is that you are only accepting work that will fit within the team's expected capacity for the current sprint. You may not accept work that you don't expect to have 100% complete (according to your Definition of Done) by the end of the iteration. If a story is too big to fit, you must break it down.

Avoid Accepting Epics Into the Sprint

While the rules of Scrum allow you to accept any story that can fit within your current sprint, it's generally a bad idea to accept epics. Smaller stories are easier to estimate, test, and swap in or out of the backlog, and tend to adhere more closely to the INVEST principles.

Remember, a story is either done or not-done, so having one big epic instead of a number of bite-sized stories is more likely to lead to a sprint failure. Making your stories smaller will make the Sprint Goal more achievable, and therefore make the team more agile during the iteration.

I personally recommend that:

  • Stories should be decomposed until they are 13 points or less to avoid epic proportions.
  • Each story should be decomposable into tasks that are expected to take between one-half to two days to complete.

Epics as Process Problems

If you find that you can't decompose an epic into stories worth less than 13 points each, there's probably too much uncertainty around the feature or too much entanglement within your feature. This should immediately trigger a conversation with the Product Owner, and possibly with the end users, in order to gain clarity and identify the minimum viable increment of functionality for the story.

There are certainly edge cases where a single large story may be justified, as long as it can fit within a single iteration. However, claiming that the story can't be decomposed is generally a "project smell" that indicates an underlying process problem.

  • 1
    +1 on "However, claiming that the story can't be decomposed is generally a "project smell" that indicates an underlying process problem" – Holly Oct 29 '13 at 22:20
  • I too agree on that, if the story cant be decomposed, theres a problem. Thanks for helping me out. – whyAto8 Oct 30 '13 at 9:15
4

Yes, you can have larger stories, just not at the top of the backlog

Your backlog should ideally have higher priority stories of smaller sizes and lower priority stories that are larger, also known as epics. The smaller, well-defined stories at the top of the backlog are ready to go into the next sprint. The Product Backlog Iceberg by Mike Cohn is very helpful to illustrate this.

In each sprint, the team can get together in a story decomposition or elaboration (also known as backlog grooming) meeting to look at the next set of priority stories, break them up into smaller chunks, write acceptance criteria and estimate story points. enter image description here

  • Is this because the stories at the top of the backlog have been broken down into smaller stories? – jmort253 Oct 29 '13 at 17:36
  • What if the team has identified the story has a effort of 40 and it has to go in next sprint? And this can not be broken as well into smaller one's? Would having 40 be okay and are there any disadvantages of having 40? – whyAto8 Oct 29 '13 at 17:39
  • 1
    @jmort253 Yes, it is. – Ashok Ramachandran Oct 29 '13 at 20:11
  • 3
    @whyAto8 In my experience larger stories are not as well understood by the team and are high risk. All you know is it is larger than a 20 and smaller than a 100. That is too wide a range for making a team commitment to completing in the sprint. If this story is not completed, your velocity may drop drastically impacting team morale and leadership perception. Try some of the suggestions here to split larger user stories. – Ashok Ramachandran Oct 29 '13 at 20:22
  • 1
    @jmort253 Good question! Yes. Epics are often useful for estimating entire backlogs or roughing out release schedules, but must be broken down sufficiently for accurate per-iteration planning. As Ashok mentioned, this is often done during Backlog Grooming or Sprint Planning. It also falls under the Negotiable mnemonic from the INVEST acronym. – Todd A. Jacobs Oct 29 '13 at 22:36

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.