Product Backlog

Product backlog can be described as evolving requirements books. The requirements here are in prioritized manner.

The product backlog contains ideas and business requirements given by the people who are interested in the product, people who are going to work on that.

These are just a small piece of information which carries a lot for the project. The product backlog can be created by doing a brain storming session with the people who are interested in the product and people who knows similar product. There is no need for the Product owner or the team to get the entire product backlog ready to kick off the first sprint. It is enough if the product backlog has contents that are ready for the first sprint. While the team is working on first sprint, the product owner can fill in stuffs in the product backlog.

The Product back log can contain stuffs like user requirements, any kind of impediments that needs to be removed or whatever is important for the product to be developed. The product backlog is dynamic requirements documentation. This document keeps changing. New stuffs get added, stuffs get deleted, and priority gets changed and so on.

As said earlier the items in the product backlog are prioritized based on the business needs and values. The product owner has the full right to change the priority of the stuffs in the product backlog. Though there may many people who are interested in the product, it will be the one person (Product owners) responsibility to prioritize stuffs in the product backlog. If someone wants to change the priority in the product backlog, he has to discuss with the product and the PO can make the change if needed.

To estimate the stuff in the product backlog, the PO sits with the team members and expertise. All these people will make an estimate on the stuffs in the product backlog. Estimation should not be done based on hours. Estimation should be made with respect to points. These estimations are subjected to changes as the team pulls the stuff from the product backlog for the sprint.

Advertisements
This entry was posted in Agile and tagged . Bookmark the permalink.

2 Responses to Product Backlog

  1. SM says:

    What is the relationship between the Product and the Sprint backlog estimation?
    For example, you have 5 user stories with its estimations.

    User Story 1: 2
    User Story 2: 5
    User Story 3: 13
    User Story 4: 8
    User Story 5: 5

    For Sprint 1 the team decided to do User story 1 and 2. (total: 7)
    During the Sprint planning you add tasks to each User story. For example:
    User Story 1 –> 7 tasks –> total: 25 points
    User Story 2 –> 12 tasks –> total: 30 points.

    Can you now tell the business that 2 (user story 1) points is approximately 25 (sprint) points?

  2. AgileSendhil says:

    User Story 1: 2
    User Story 2: 5
    The estimated story points gets changed during the sprint planning meeting only if the team feels that if there is more or less work involved than they have estimated during the release planning meeting.
    Les’s assume that during the release planning meeting , the team estimates the “User Story 1:” as 2 points .
    Now when the same story is pulled into a sprint and during the sprint planning meeting the Product explains about the story and after hearing the explanation the team feels that the story needs more work than it had thought during the release planning meeting , then in that case the team will reestimate and come out with new story points (Inyour case it is 25).
    So there is no point in Comparing 7 with 25..

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s