Thursday, February 12, 2015

Estimating Product Backlog Items - why to do it?

In our team we have stopped estimating product backlog items.

In our context I believe it's fine not to spend our valuable time estimating product backlog item. Because, there is no need to tell, where the team would be in two or three months. Also since team is working on small small features PO wants all of them. For us having estimate will not change any behavior, so I would say it's okay. 

In my past projects we always estimated PB. An estimate represent the cost of an item and helped PO successfully prioritize the items. Also estimation helped us doing the rough long term projection on when team would be done with the product backlog items. We estimated product backlog items during our PbG ( Product backlog Grooming) meeting. We use to have PbG meetings 2 to 3 days before sprint planning meeting. This gave enough time to PO to get the backlog prioritized and ready for sprint planning meeting. At times we did adhoc Product backlog estimation based on PO's need. 

It is nice to experience both side of spectrum. 



  1. When you say "estimate" do you, as most people do, mean "estimate the effort" (or perhaps the time needed) or do you mean "estimate the benefit" ?

    I think estimating the benefit (or value if you prefer) is far more valuable (sorry for the pun) than estimating the effort.

    It seems to me that a lot of energy is spent debating effort estimates (and whether you should do it at all) and almost no effort spent doing or debating benefit estimates.

    1. Sorry for my late reply, I was on vacation and did not have good internet access. I was referring to effort estimation or guesstimation. I have seen advantages of doing estimations too, so would not entirely go in favor of not doing it but lot depends upon project and team you are working with.