When is a good time to size product backlog items? I have come across varied opinions on this topic. While for some it makes sense to size stories during a backlog grooming session, others suggest that PBIs should be sized in the initial part of sprint planning. Additionally, I have seen teams size PBIs multiple times, 1) during Product Backlog grooming to help Product Owner with predictability and 2) during sprint planning as the team gets to the next level of details for the PBI. So what is the right approach?
The key objective of sizing stories during backlog grooming it to provide relevant data to the Product Owner to prioritize the product backlog and provide an opportunity to the stakeholders/customers to make long term predictions.
While I have had teams size stories multiple time, this approach feels redundant. Following are some ways to size your product backlog items:
1. Periodical grooming (monthly/quarterly) – This can be a scheduled periodical meeting where the team can size stories for the next 2 to 4 sprints. This can be done on a day between sprints to allow the Product Owner to plan for a larger goal and write additional stories to achieve the goal as needed. Deliverables at the end of each iteration will help the PO to re-plan and re-prioratize the product backlog.
2. Once every sprint – Some teams like to get into a backlog grooming session once every sprint. This is typically done when the team wants visibility into what is coming up in the immediate next sprint. The team collectively spends one hour to go through the highest priority stories in the backlog.
3. As needed after Scrum – With some teams a Product Owner’s presence during the daily Scrum is an indication of the fact that there are stories to be sized. This typically works well as the number of stories to be sized are generally lesser in number.
Teams having to size PBIs directly during sprint planning generally result in issues. Having the team to size the stories during the grooming session works best. This also presents an opportunity for the teams to identify dependencies on other teams and notify them, identify spike candidates as needed and brings about an overall visibility into what is coming next.
So if you have a un-sized product backlog, go ahead and get it sized by the team and make it an ongoing activity to deliver value continuously.
Nirmaljeet's Blog 