As an expert in agile methodologies, I want to clarify that the number of user stories in a sprint is not a one-size-fits-all number. It's a common misconception to think that there's a magic number that applies to every team. The optimal number of user stories for a sprint depends on several factors, including the team's velocity, the complexity of the stories, the team's capacity, and the sprint length.

Firstly, velocity is a measure of how much work a team can complete in a sprint. Teams that are new to agile or have not yet established a consistent velocity might find it challenging to determine the right number of stories. As teams mature and their velocity stabilizes, they can better predict how many stories to take on.

Secondly, the complexity of the user stories plays a significant role. Simple stories that can be completed in a few hours might allow for more stories in a sprint compared to complex stories that could take several days or even a sprint to complete.

Thirdly, the team's capacity is another crucial factor. A team's capacity is not just about the number of developers but also includes the work of testers, designers, product owners, and other roles that contribute to delivering a user story. The more roles involved, the more communication and coordination are required, which can affect the number of stories a team can handle.

Lastly, the sprint length is a factor. Teams that work in two-week sprints might find that they can take on more stories than teams working in one-week sprints due to the longer time frame to complete work.

The reference you provided suggests that having 3-6 user stories per iteration per developer is a bad rule of thumb. This is because it doesn't take into account the variability in team size, story complexity, and other factors. For a team of 7 developers, aiming for 20-40 user stories could indeed be overwhelming and likely indicates that the stories are too small and might need to be combined or that the team is overestimating what they can achieve.

Instead of a fixed number, teams should focus on delivering a certain amount of work, measured in story points or ideal man-days, which reflects the team's capacity. This approach allows for flexibility and accommodates the natural variability in story size and team performance.

In conclusion, there's no definitive answer to how many user stories should be in a sprint. It's about finding the right balance for your team, which comes from experience, reflection, and continuous improvement. Teams should aim for a sustainable pace that allows them to deliver quality work without burning out.

read more >>

User Stories Per Sprint. I've heard some coaches recommend --3-6 user stories per iteration per developer--. That's a bad rule of thumb. For a team of 7 developers you would have over 20-40 user stories which is likely way too many.May 29, 2015read more >>