Last time I wrote about sprint planning which is one of four formal events prescribed by Scrum.

In this post I explain what product backlog grooming is, when it is performed, and how it is done.

Backlog grooming is often performed throughout the sprint. Perhaps this is one reason why it’s not considered a formal event.

However, many teams do backlog grooming as an explicit meeting, and some people think it should be incorporated as a formal meeting in the guide, too.

Every sprint begins with a planning activity. This is when the Scrum team decides on the work to be done in the iteration ahead.

Sprint planning is divided into two parts.

During the first part user stories are analyzed, evaluated and estimated. After that, the developers determine a reasonable workload that they think they can commit to.

During the second part, selected stories are analyzed in more detail by the developers (remember, I use the term developer for everyone building the product, including coders, designers, testers, documenters, and so on).

“Time is what we want most, but what we use worst.” –William Penn.

Never is it more true than when it comes to estimating.

Indeed, to most people estimating effort is tightly coupled to time. How long will it take? When will it be ready?

This is futile: time is a moving target and calendar time, in particular, next to impossible to predict.

A better approach is to estimate the size, or complexity, of work, and to derive duration based on velocity.

The product backlog is the bucket from which you pull work. It’s a list of all items that potentially make it into the product. It’s the single source of requirements. That sounds easy enough. Perhaps it is, too. Yet sometimes it isn’t obvious what to put in the backlog, and how to select what items to work on next.

One challenge is to manage non-features such as technical items and bugs (in the rare case you have any, of course). People have different strategies to deal with the not-so-obvious stuff.