Is it a good Scrum practice to use large story-point numbers for effort estimation?

Question

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?

Answer 1

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.

Answer 2

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.