Pull quote artwork: Zero-point items usually require at least some effort.

Should You Use Zero-Point Estimates on Your Product Backlog?

I'm occasionally asked about the merits (and whether there are any) of putting an estimate of zero on user stories. You may have noticed that many Planning Poker decks include a zero card.

So, what's the logic behind a zero-point card?

Remember that story points are used to estimate the [effort](/blog/story-points-are-still-about-effort) involved in delivering a product backlog item. A zero-point estimate simply indicates that delivering that item does not require "any" effort. That is usually an exaggeration. The product backlog item will take some effort but usually so little that the team will not want any velocity credit for it.

As an example, I looked in the recently completed items from the www.frontrowagile.com site and found a zero-point user story. The story had to do with a file that is generated each night and then automatically imported into our accounting system. The story involved changing the order of a few columns in the file and changing how dates are formatted. The story took the team about 15 minutes to code and test.

If the team had estimated this as a one, they would have had a higher velocity for doing that trivial amount of work. But in the next sprint, I might have expected them to maintain that velocity, which they might not have been able to do; a one-point story is normally a lot more than 15 minutes of work.

**How Can Zero-Point Stories Deliver Value? **

Sometimes I'm asked if product backlog items are supposed to deliver value, how can a zero-point product backlog item deliver value?

The value of a product backlog item is independent of the work to deliver the item. Think of the relationship between calories and the size of a food item. There really isn't any.

I remember when one of my daughters was young, she came home from school fascinated by the idea that celery has so few calories in it that we theoretically burn more calories chewing it than are in it. So, I could have a massive bowl of celery and consume very few calories. The same size bowl of ice cream would, unfortunately, have many more calories.

So it is with value, and the effort to deliver a product backlog item. A product backlog item with a zero-point estimate to develop it can still deliver value. Changing the sort order on the report in the example above saved our accountant a lot of manual time.

Zero-point stories are not something I recommend you use a lot of. But, used judiciously, they can still have their place on a product backlog.

Article artwork for Should You Re-Estimate Unfinished Stories?
Article

Should You Re-Estimate Unfinished Stories?

Featured

We avoid having unfinished work at the end of a sprint, but it sometimes happens. Here’s what to do.

A folding ruler sits inside a circle, upon which rotate planning poker cards, gears, and a clock. Text to the right of the image reads, Story Points are an Estimate of Effort, as Influenced by the amount of work, complexity, risk and uncertainty.
Article

What Are Agile Story Points?

Featured

Understand what story points measure and why they are often misunderstood.

Product Backlog Refinement Checklist
Download

Product Backlog Refinement Checklist

Featured

Bring this practical checklist to your next refinement session to decide whether backlog items are clear and ready enough for a sprint. Download The Product Backlog Refinement Checklist and use it in your next…

Article artwork for Why I Don't Use Story Points for Sprint Planning.
Article

Why I Don't Use Story Points for Sprint Planning

I don't use story points for sprint planning because story points are a useful long-term measure. They are not useful in the short-term.

People collaborating during a Mastering User Stories workshop.
Workshop

Mastering User Stories

A one-day course where your team improves real backlog items while learning how to write, split, and refine better stories.

Guide

Estimating Unknown Work

Agile plans are more useful when they account for both the work a team can see and the work the team expects to discover later. Ignoring unknown work makes a plan look more certain than it is.