Let´s suppose there is a story of 8 story points, and several developers are working on it simultaneously. Any take on these types of cases? Should be fine? Could this be considered for completion in a 2-week sprint?

  • 1
    Story points are an abstract dimension for the effort you put into the work. It means different things to different teams. Can a story estimated as 8 SP and multiple developers working on it at the same time fit into a 2 week sprint? Only your team can answer this question. Ask them.
    – Bogdan
    Commented Dec 28, 2022 at 14:27
  • Please edit the question to limit it to a specific problem with enough detail to identify an adequate answer.
    – Community Bot
    Commented Dec 28, 2022 at 21:47
  • You haven't identified a problem. What is the real-wordl problem that having a certain story size or multiple team members involved is creating for your project? As it stands, this doesn't represent an answerable question, and requires more context or focus to provide a useful answer.
    – Todd A. Jacobs
    Commented Jan 7, 2023 at 19:09

2 Answers 2


You certainly can bring a large story into a sprint if the team feels they can complete it.

However, there are a few things to consider:

  • Larger stories tend to have more uncertainty and therefore more risk of 'discovery' - finding that the story is bigger than you anticipated
  • Larger stories will tend to only get finished late on in the sprint, which can result in a bottleneck of testing
  • Larger stories tend to have more dependencies than smaller stories

While it is fine to bring the story in to the sprint, you might also want to consider breaking it down if you can.


It's up to the team to define a Story Point and what it means to them. For most teams, an increasing number of story points represents an increasing effort needed to complete the work and lets the team compare two pieces of work in terms of effort. Any specifics need to come from the team.

Since this question has the tag, it's worth noting that story points are not a required element of Scrum but are a complementary practice that some teams find helpful. In the Scrum framework, the only rule about the size of a Product Backlog Item is that each Product Backlog Item that is considered ready for selection at a Sprint Planning event when it represents work that the team can complete within a single Sprint.

Regardless of whether or how the team sizes work prior to Sprint Planning, any kind of pairing or mobbing that the team is planning on doing should be considered when the team is crafting a valuable and achievable Sprint Goal.

Not the answer you're looking for? Browse other questions tagged or ask your own question.