Programmers Stack Exchange is a question and answer site for professional programmers interested in conceptual questions about software development. It's 100% free.

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

Recently an item has been added to the Product Backlog by product owner which says "When I go to login page from x page, I see an error. I want that error to be removed".

It seems to me that this is not a use case, and shouldn't be a PBI (Product Backlog Item). However, when I discussed it, scrum master told me that user stories are not PBIs and, a PBI could be a bug report, a task, a user story, anything, and literally any item that should be addressed first.

I'm not sure about this. Also I can't find a good definition of PBI on the web. So, my question is, what sort of things can get into the Product Backlog as items? Does a product backlog item maps to a user story? Are they the same?

share|improve this question

Does a product backlog item maps to a user story? Are they the same?

Not necessarily, but in general, they do. Like your scrum master said, other things can be product backlog items, too. However, it depends on how your SCRUM works. Some teams have a separate bug backlog which is taken into consideration for sprints as well, while others keep such things in the product backlog.

Two separate logs make it more difficult for the product owner to prioritize tasks, as now two logs have to be taken into consideration for the next sprint. But they do offer a better oversight and both can be prioritized separately.

So, my question is, what sort of things can get into the Product Backlog as items?

This can be anything which is part of the product vision and the journey to the product you want to create. It mostly contains requirements (user stories) but can also contain actions or technical things that do not directly belong to the product (e.g. "Buy a new server for dev team", "Create advertisement for product"). The backlog should avoid uncessary details and should not try to micromanage technical things. The product backlog can contain anything that delivers value to the product.

There's not the one true Scrum. Sometimes separate backlogs are a better way to manage the product, sometimes they are just in the way. Find out what works for you best.

share|improve this answer
Good explanation @Falcon. Can you guide me to some online resources about how to consider something as a PBI? I'm really grateful for the quality answers you provide. Thanks :) +1 – Saeed Neamati Aug 20 '11 at 10:29
@Saeed: How about this? It also contains links to sample product backlogs. – Falcon Aug 20 '11 at 10:39

When working on bugs, we add them to the backlog and call them bug stories. By adding bug fixes te the backlog in this way, it's clear it's not just the bug fix. We can add other tasks to make sure automated tests are written and verification is done. It also makes it more explicit that the DoD should be followed.

We've never used the term PBI (even though our backlog tool calls them that), it's always user stories, bug stories or simply just stories.

It's mainly just your team's choice of terminology and as long as you're all clear what is what it doesn't really matter.

share|improve this answer

@Falcon has explained it well. One page that has a formal definition is: What you have described is not to be placed in product backlog according to that discription at least.

share|improve this answer

Your Answer


By posting your answer, you agree to the privacy policy and terms of service.

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