We estimate stories as 1, 2, 4, 6, or 8 points. Consider a story with less development work but huge testing effort. Let's say we estimate that story as 8 points.

We see the following options:

  1. Let the story be 8 points, and be ready for the story testing to slip to the next sprint. This way development and testing are included in one story, but the team doesn't get any points for the work done in the current sprint. They get all 8 points in the 2nd sprint, or when the testing ends.

  2. Split the story for testing purpose, i.e. development and some minor testing in one story, which can be completed in one sprint, then carve out the second story just for testing purposes (a testing-only story). This way the team gets some points in both the sprints.

In my previous experience, we have been opting for option 1, but in my current project people are more keen on option 2. I'm not sure if it is a correct way to split stories.

  • 2
    Getting points is only a psychological aspect. With stories, it's either all or nothing. No middle ground. Period. You are ONLY done, when you deliver something that passes the acceptance tests. If it takes two sprints, then your sprint length needs to be doubled. It sounds like children asking for a few points for their attempt that is not complete. You may give it to them but it's not in the spirit of agile, IMHO. – PhD Oct 27 '13 at 19:40
  • @PhD I think its important to highlight that not being able to complete a particular story within one sprint, is not a valid reason to change the sprint length. Rather that the story was not split correctly. See this article for more info on why sprint length shouldn't change: benday.com/2014/07/24/really-bad-idea-change-sprint-length – JTech Jul 25 '17 at 5:31
  • I have been thinking the same thing. When working Kanban it makes sense to just have one story that goes through all states and have stories change hands. But in scrum, bundling up all story points into one card which needs to change hands from a developer to a test engineer irks me, it makes planning individual capacity difficult and also throws burn-down out of whack when stories carry on to the next sprit. – Brett Ryan Mar 6 '18 at 9:58


Neither of your stated options are truly agile. You are misusing points in an attempt to represent progress or to "hold people accountable." Neither is appropriate within the Scrum framework.

Points are an estimating tool. They are only meaningful in the aggregate, and are primarily needed for estimating team capacity during Sprint Planning. Using them as a productivity metric is misleading, and continued misuse of the story-point system will eventually harm both the team and the project.

Points are Not Rewards

This way the team gets some points in both the sprints.

In Scrum, a story is either done or not-done; it is never partially-done. You can certainly rig the system by artificially decomposing stories so that you can "earn" points in a Sprint by completing certain stories even when the real underlying feature isn't complete, but this doesn't serve any practical purpose other than to inflate velocity. Inflated velocity will ultimately skew your estimates, hurt the team, and damage your project. Don't do that.

Points are also not rewards. They aren't lollipops that you hand out for a job well done; they are simply a work-effort metric. Specifically, story points:

  1. Are converted to a velocity metric by aggregating over an historical window, tracking the team's capacity for work over time.
  2. Are used as a sanity-check to determine if a story can deliver its intended value within a single iteration.

Points Measure Capacity

Points are both an estimating tool and a means of tracking team capacity over time. When estimating, story points tell you:

  1. How much effort the team thinks a story will take.
  2. Whether or not the story (in its entirety) can fit within the current iteration.
  3. Whether the team should accept the story into the sprint as-is, or whether the team needs to work with the Product Owner to refine, clarify, decompose, discard, or re-scope the story to achieve the current Sprint Goal.

Points also act as a proxy for team capacity over time. Earning points adds no value to the project, but being able to say that the team can usually complete an average of 12-16 points in a typical iteration helps the team estimate its capacity to accept stories during Sprint Planning. This helps the team avoid over-committing, prevents setting the team up for failure by creating an unsustainable work-load, and avoids planning a sprint that will not meet the stated Sprint Goal for the iteration.

Stories Should Fit Within One Sprint

If your stories can't fit within a single sprint, then you either have an epic that must be decomposed, or your sprint length has not been optimized for your project. There is always a trade-off involved in determining the optimal sprint length for a project, but the challenge of writing stories that fit into a finite time-box remains a constant challenge.

In Scrum, a story should be a full-stack, vertical slice of functionality that engages the whole cross-functional team. Testing is never a separate story; rather, it is an integral task required to ensure that a given feature meets the formal "definition of done" as defined by the project.

Stories that are expected to extend past the end of an iteration indicate a process problem that must be fixed during Backlog Grooming or Sprint Planning. Likewise, stories which don't meet the definition of done are also process problems that the team urgently needs to address.

  • You wrote that a story "engages the whole cross-functional team". It sounds like each team member needs to work on each story. In case of many of the stories (which are small by definition), it is often just enough when 1-2 team members work on it (e.g. one doing the implementation, the other code review and functional tests). I understand that you wanted to emphasize "cross-functional" part of that expression and not the "whole [...] team" part. Right? – Paweł Polaczyk Oct 29 '13 at 8:42
  • @PawełPolaczyk Each role ought to be involved with each story. There may certainly be exceptions, but most stories should involve developers, testers, business analysts, technical writers, and other roles in the estimation or completion of the story. Your mileage (like your story granularity) may vary. – Todd A. Jacobs Oct 29 '13 at 13:49

When looking at problematic stories, the best advice is to use INVEST principles and in particular:

Stories deliver value

If QA is an activity that must be performed in order to deliver at all, then you can't split it off. Did you have a "definition of done" meeting? Does "done" include QA?

If your story doesn't deliver value, it's not a story.

Stories are small

All stories must be less than one sprint in length in order to be planned. Split your story by delivering a subset of the features (less value, but still some value).


Option 2 only seems valid if you view testing as a service, and not as a responsibility of the team. If that's the case, I'd question how agile the team is and do you really need to squeeze 2 separate teams (dev & qa) into one sprint. If your goal is to be agile, it might be worth not to distinguish between dev and test and consider a story "done" when it is properly tested. That way you'll end up estimating the overall work needed to be done as a team, and not just sub-parts of it.

  • So you are saying option 1 makes more sense if its an agile team? I'm also a firm believer of this because if we split the story based on the number of points we can score in a sprint, it makes me feel I'm back to waterfall. – Saurabh Oct 26 '13 at 4:52

Be careful when splitting stories

If you find yourself splitting a user story ask yourself "does this story I am creating add value on it's own?". If the answer is no, then it should be a task as part of a larger user story.


Right answer is fully depends on your goals.

If the goal is to meet scrum requirements: you shouldn't split story into, let's call it tasks as there won't be a value inside each of them.

Nevertheless if you see an option to make more transparency and predictability within your development process: splitting tasks into small solid items will bring you a lot of insights (e.g. which part of your delivery pipeline is a bottleneck, etc)

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.