Why have a backlog?

An ever prioritized list of requirements - Does that not sound as a basic need for a successful team? The team need not be a scrum team, need not even be agile for that matter. Any software development team, anywhere in the world is asking itself everyday, what should be the next item to look at!

Being so fundamental, why do most matured organizations ignore its significance? In my opinion, a simple shared list of items that is editable for entire team is all that is required. A twiki and bugzilla combination should just work lovely. Yet, teams just dont do it. I strongly believe, this needs discipline, a cultural shift and a deep ownership/commitment to product and sense of belonging to a team.

If I ever become a manager, I will ask my team to:
* Create a ticket in bugzilla for every item that it works upon.
* Use a twiki with a table rule to pull all bugzilla items based on a definite tag that signifies that this item is a backlog item.
* Continuously someone owns and updates these tickets with priorities. Marks items for releases and calls out risks.

Now, for your team, if bugzilla is too much, you may just use a shared xls or any of the open and free scrum tools.

Not doing this activity seem to boost an individual team member's productivity; but, come on, there is so much work coming from so many stakeholders, that you are going to spend hours in status meetings. QA will get thoroughly confused on what is that they need to test. Dev team will never read their manager's mind properly and will show sheepish face on wrong item selection when manager is away.

If you are already a manager and nothing above convinces you, at least, for god's sake, you wish to have a self-sustaining team. This is the first step to get your team in that mode.