Month: May 2014

When to size Product Backlog Items?

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?

Image

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.

Is release planning becoming redundant?

Talking about Agile projects, release planning used to be discussed about just as frequently as sprint planning or sprint review, however; lately I have observed teams not really emphasizing much on release planning to make it feel like something non critical.

For starters, release planning was looked at a formal release at the end of x number of sprints where x could be anything between 2 to 6 sprints. However today, teams that are trying to derive classic benefits of Agile release their code more frequently than ever before. I have known of teams releasing code every sprint to teams that release code multiple times during the sprint. I came across a talk about continuous delivery at Etsy where the code is released in production 35+ times each day. This equates to a release less than every 15 minutes.

Speaking about teams that deliver that often, its quite certain that not much time is being spent planning for what needs to be delivered 2 to 3 sprints down the line. Planning happens in a “just in time” manner knowing the immediate needs of the customer.

Thinking through, it probably is time to redefine the term “release planning” itself to refer it as a method that allows customers to realize  value on a continuous basis allowing for full customer involvement and speedy issue resolution or is it time to say “Goodbye release planning”?