Reading an excellent post on Product Backlog from Roman Pichler – The Good, The Bad and The Ugly Product Backlog.

The product backlog is the roof that covers a Scrum Project.  So what’s good, bad and ugly about it?

Good – Simple list. Flexible. Supports sprint and release planning.

Bad – Needs that are hard to describe in a list-form become difficult to maintain. Often requires another tool. Also, when it becomes challenging to use a list when release planning is not feasible.

Ugly – When requirements are stated with unnecessary details, and the list is of hundreds of items, product backlog becomes ugly and hard to deal with.

The way I see it, bad and ugly part of product backlog have more to do with how it is used and less to do with product backlog itself.

Nonetheless they are important and cannot be overlooked. Similar to how a Scrum Project evolves as it progresses, implementation of product backlogs will also evolve.

That’s why Roman talks about an alternative to Product Backlog – The Product Canvas, which is a really good tool to see and use.

Progressive elaboration is the key nature of things in Scrum, isn’t it?

I have seen many Scrum novices arguing and saying that Estimates are not useful as we are anyways putting in our focus and energy on the most important tasks.

That’s seldom true. Estimates are important and provide a rough idea about how future should shape itself.

Read this insightful post on Estimation in a Scrum Project  from Mike Cohn. It shows a dialogue between client and the Scrum team.

It is important to note that Scrum projects are part of real world that requires some idea about what will be delivered. Any Scrum team cannot take the flexibility that the framework provides for granted.

The flexibility is to eliminate the unnatural, rule-powered ways from the project. It’s not to disregard the need of business.

Here’s my take on it:

“If it doesn’t make a business sense, it is not the right implementation of Scrum.”