Posted by jc-Qualitystreet on 2011/02/01
The product backlog is a prioritized list of everything that might be needed in the product. This is the thread of a Scrum Agile project.
My Product Backlog is DEEP…
The acronym D.E. E. P. (detailed appropriately, estimated, emergent and prioritized) summarizes key attributes of a good product backlog.
Unfortunately among agile teams, few product backlogs now meet these criteria, but surprisingly (or not), the question of the tools to manage it seems to be more « exiting » … From dedicated tools, to Excel or Google spreadsheet; from Sharepoint to Jira or even QualityCenter 🙂 … which tool to choose? That’s forgotten pretty quickly, another key characteristic of the product backlog: its physical aspect!
My Product Backlog is DEEP… and PHYSICAL
Having a physical version of the product backlog, visible and easily accessible is crucial. Associated to the burnup chart, it’s a key element within the information radiator of the project.
Indeed, unlike a virtual (electronic) product backlog, the physical product backlog:
- offers to everyone (belonging to the Scrum team or not) a real time visibility on the progress of the product development: what we’re doing, what we did and what we need to do to finish the product;
- is a strong sign of transparency and openness
- gives a meaning to the work of the team (source of motivation and engagement);
- provides each team member with a clear idea of the big picture.
An agile state of mind and some prerequisites
The cost of initialization of a physical product backlog (for example the writing effort) is minimal. However, its effectiveness requires that:
- the physical product backlog belongs to the information radiator located where the team works (closed to the Product Owner in a collocated environment);
- the physical product backlog becomes a real meeting point for the team and the Product Owner;
- the product backlog is groomed and managed continuously: leaving a product backlog abandoned in a corner of the wall is the sign that something goes wrong.
Obviously, electronic versions of the product backlog remain essential for distributed teams operating in remote environments. Yet even in these contexts, a return to simplicity and value is often useful. Tools must only exist to make processes more efficient and to facilitate the work of people.
So a virtual product backlog tool should remain a source of value, and should be neither a constraint nor a waste.Tweeter