Create the Product Backlog
written by gunther gerlach-2009
The Product Backlog, in its simplest form, is a list of things that people want to be done to the product, in priority order. Anyone can add anything to the Product Backlog. Anyone. The agile Scrum process, and agile development principles generally, are collaborative and inclusive. There is no longer any need to say no.
Only the Product Owner can prioritize the Product Backlog.
The Product Backlog can contain anything. Anything relating to the product that is. Bugs. Enhancements. Whole projects. Issues. Risks. Anything. Having said that, items on the Product Backlog should ideally be expressed in business terms that are of some value to the user (or customer, or business). Not as technical tasks.
Functional requirements should be expressed as features. Non-functional requirements can be put on the product Backlog too, for instance ‘the product needs to be faster’, ‘we need to ensure the product is secure’, ‘we need to get off the old platform’, ‘there’s a high risk of downtime due to a single point of failure’. These might not be features, as such, but they are completely justified as items on the Product Backlog
Prioritizes; The Product Owner prioritizes the Product Backlog. They don’t categorize the priorities 1, 2, 3 or anything like that. The priority is determined simply by the order of the list. The Product Owner puts the Product Backlog in priority order.
Things at the bottom of the list may be way off and may or may not ever get done. Things down the bottom are likely to be fuzzy and ill-defined. Don’t waste time defining things you may never get to, or not get to for some time. If something is a bad idea, the Product Owner should explain to whoever requested it why they are removing it from the Backlog. However, if something’s not such a bad idea, although never likely to be done, just put it in its rightfully low place on the Backlog and explain to the requester where it fits with priorities. Actually this is just like queuing. Or standing in a line. We’re all used to that. People will generally accept it. Providing the authority of the Product Owner has been communicated and has management support, people will take their place in the queue.
All too often in development teams, there is no clear visibility of the queue. People don’t know how long the queue is. And they don’t know how many are in front of them. This generally leads to impatience and complaints, because it’s the only way to push in and get further up the line… Visibility of the Product Backlog can solve this problem.
