Our Agile/Scrum team follows the Fibonacci sequence for story point estimation. However, it is not clear whether we should have any zero point stories at all. Even though a story may have minimal development effort, it still needs to be tested, regressed, documented, and deployed. So, there is always some overhead associated with any change.

3 Answers 3


A story point is a measure of effort to implement a user story. Because every change requires some measurable time of development, peer review and testing, documentation (created or updated), and deployment, there has to be some level of effort put into it. This precludes 0 story point stories.

  • While this is true, my team sometimes has a zero point story. We reserve that for stories where there may be only about an hours worth of work, which is usually the result of us coordinating with an outside team, such as when we are awaiting a security audit. Feb 8, 2013 at 12:33
  • @BryanOakley I wouldn't consider that a story. It depends on your team's definition of "story", though. I would still give it at least a story point (or fraction if you are using fractions) since it takes time away from at least one person on your team. I would simply make it a task or an action to take that might even live outside of the iteration or cross between iterations, but take it into account when choosing what stories to bring into the sprint.
    – Thomas Owens
    Feb 8, 2013 at 12:58

Zero-Point Stories

This is an area of debate within the agile community, and I think that reasonable people can disagree. However, you're quite correct when you say:

Even though a story may have minimal development effort, it still needs to be tested, regressed, documented, and deployed. So, there is always some overhead associated with any change.

Because every story has overhead, whether it's task-switching, preparing its demo for the Sprint Review, or integration testing, no story truly requires zero work effort.

Alternatives to Zero-Point Stories

Since the work isn't "free"—and therefore non-zero—you have a few options:

  1. Use half-or quarter-points.

    Remember, a story point is a unit of measure relative to a one-point baseline story. So, a minor tweak that you can do with minimal effort might be 1/2 or 1/4 of the effort required for a typical story, and should be counted as such.

  2. Roll up small stories into a mini-epic.

    While I'm not a fan of this approach, I consider it valid. You could take any number of small stories, and roll them up into a single one- or two-point story. For example, rather than having eight quarter-point stories for adding individual users to a system, perhaps you can have a single two-point story to handle all of them.

The benefit of the first approach is that it ensures that all tasks are captured, and that stories can be done or not-done independently of one another. The benefit of the second approach is that it simplifies bookkeeping, but at the cost of causing the entire story to be failed if any one sub-task is incomplete at the end of the sprint.

Pick whichever method works best for your team. Your mileage will vary.


Zero point for Defect card

Some companies (including mine) are using zero point for "defect" card. We agree that defect card is not the thing customer want so we estimate it as zero even we have to put the effort to fix it. The velocity of that sprint will be lower than others because we have to take time to fix this zero story point thing. This will be shown at the end of sprint that we had defect card(s) to work on and this can show the quality of work in the team (it could be human defect or requirement defect).

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge that you have read and understand our privacy policy and code of conduct.

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