What is a Backlog?
Why do we need a backlog? Is it just an ordinary to-do list? Is it any better than my to-do list? How might I use it most efficiently?
Coming from the background of traditional project management these might be questions that arise when thinking about a Product Backlog. Let's see what's what.
As described here, a Product Backlog describes everything that is needed in a Product. It should be the single source of requirements, the holy grail of new features if you would like to call it so.
In a SCRUM team, the Product Owner is responsible to keep the Product Backlog tidy, to have all the requirements formulated in an understandable way for everyone, and have to issues ordered and prioritized to fit the projects current needs. Also, he's the one making sure the Product Backlog is always up-to-date.
Important to remember is that a Product Backlog is never "finished". It is always growing, so as the Product matures, the Backlog matures & grows too.
Product Backlog Refinement
Whenever it suits the Project Team, most of the time between Sprints, there is a so called "Product Backlog Refinement" happening. This is basically the development team and the Product Owner sitting together, discussing, splitting and estimating the current issues in the Product Backlog until every member of that group is happy with the status of the Backlog.
But is it now a to-do list?
Yes, and no. It is not a to-do list in the classic sense of just ticking boxes, issues in the Product Backlog are estimated using Story points, and they are ordered to fit upcoming requirements for the Product. But yes, it is a list of upcoming work that needs to be done during the lifetime of a product.