Key: Product Backlog

1. Product backlog should only contain items which provide business value.

Product backlog generally start getting cluttered with technical tasks, without considerable visibility into business value, which makes it difficult to judge right priority.

2. Product backlog should not contain items which cannot be consumed in next 2-3 product releases.

Having too many items in product backlog clutters, and makes it difficult to make priority decisions.

3. User stories to be consumed in next 2-3 sprints should be mature with acceptance criteria.

Freezing acceptance criteria too early or too late may require rework, so apply "just in time" strategy to freeze them at the time they are ready for consumption"

4. Precise feature statement

Feature statement should be a one-liner statement of demand. Use of conjuctions (“and” or “or” or “if” or “until” or..) generally means features are being clubbed together and candidate for decomposition.

Almost all industry experts agree that writing feature statement in first person is very effective in stimulating thought process clearly.

As a user, I want/need to do something, so that I can achieve this

4. Acceptance criteria should be limited but not scarce

Acceptance criteria is the confirmation of expectations. It should be bite-size chunk of business value, but having less than 3 bullet points will make user story very small and difficult to manage and provide visibility into. Having more than 7-8 items generally means story is getting larger, and should be broken down.

5. Release criteria must be a product backlog item to be discussed and check-listed in every sprint

Many of the technical tasks including system abuse parameters can become part of release criteria, and should be allocated some time for execution during every sprint.

6. Entire product backlog items must be prioritized using stack-ranking and estimates.

Initial resource estimation and stacking user stories is a good way of visualizing product roadmap. Generally, I prefer to stack rank for every quarter with 100 point estimate for every stack.

For a enterprise product with 2 releases a year, quarterly stack ranking for 3 releases (6 stacks) is a good idea.