Elements of a Effective Backlog

Your Wish List is not a Scrum Backlog.

I've seen lots of list that are referred to as a backlog.  List on paper, in spreadsheets, in powerpoint, on whiteboards, wrapped in a rubber band on index cards - they can take many forms - yet the form is not what makes a wish list into a backlog.  So what are the necessary and sufficient attributes of a backlog?

A list becomes a backlog when:

• the items are sized (estimated) by the Development Team that will implement the item
• the items are ordered (prioritized) by the Product Owner by delivery order
• the items are visible (instantly) to the team and the stakeholders in this ordered list
• the stories in the list are understood to the team (well enough for sizing)
• items that reference additional information or requirements are easily obtained (wireframes/mock ups/technical specification/etc. via a well known location)

This list of elements of an effective backlog follows from the principle of transparency -- the team should be able to easily see the future work, interact with the work, and mutate the work as additional knowledge is generated.

A Backlog has: Order, Size, Visibility

Very few of the teams and organizations I work with would pass this acceptance test of a backlog.  And everyone of them have benefited from making the backlog visible and interactive.  The shared understanding of the product, how it will be implemented, and when that will be completed is achieved by this very basic exercise in sharing.

See Also:
A JIRA List Is Not A Scrum Product Backlog by Craig Larman and Tim Born
Transparency - Two Way Visibility