This post is part of the series “Z2A: From zero to agile”.
Here is an example of how a backlog can be quickly created with a tool like a spreadsheet.
Each row represents the information for a topic (user story/issue/etc.) and includes the following fields:
|PRODUCT BACKLOG (example)|
|ID||Name||Import.||Estim.||How to demo||Notes|
|1||Deposit||30||5||Log in, open deposit page,
deposit €10, go to balance page
and check that it has increased by €10.
|Need a UML sequence diagram.
No need to worry about encryption for now.
- ID – a unique identification, just an auto-incremented number. This is to avoid “losing” topics when you rename them.
If you have a separate bug tracking system, like Jira or Bugzilla, you can use their tracking ID.
- Name – a short, descriptive name of the backlog item, typically a functionality or an error correction. For example “Check transaction history”. Clear enough so that the team members and the product owner understand what we are talking about, and clear enough to distinguish it from other backlog items. Normally 2 to 10 words.
- Importance – the product owner’s importance rating for this item. For example 10. Or 150. Lower numbers mean more important. I tend to avoid the term “priority” since in many cases priority 1 is considered the “highest” priority, which gets ugly if you later on decide that something else is even more important; what priority rating should that get – priority 0? priority -1?
When dealing with customers projects (but also on internal projects) it can be useful for the product owner to group the importance values according to the importance levels in terms of the contract.
It is a simple classification, here’s an example of such rules:
- All items with importance < 100 must be included by contract, or else we’ll have to pay a huge penal.
- All items with importance 100 – 199 should be included but we might do otherwise a quick follow-up release.
- Items with importance 200 – 299 are required, but can be done in the next release.
- Items with importance > 300 are speculative and might never be needed at all.
- Initial estimate – the team’s initial estimate of how long this will take to implement. The unit is “ideal man-days, with ideal team size”.
Ask the team: “if you can take the optimal number of people for this job (not too few and not too many) and work undisturbed, after how many days would you come out with a finished, demonstrable, tested, releasable implementation?”.
If the answer is e.g. “with 3 guys it would take 4 days” then your initial estimate is 12 ideal man-days.
It’s easier to start with a measure unit like days that is familiar to everyone; more sophisticated units like “story points” can be used later.
- How to demo –a high-level description of how this backlog item will be demonstrated at the sprint demo. This is essentially a simple acceptance test spec. “Do this, then do that, then this should happen”. If you practice TDD (test-driven development) this description can be used as pseudo code for your acceptance test code.
- Notes – any other info, clarifications, etc.
Sometimes additional fields can be added to the product backlog, mostly as a convenience for the product owner to help them sort out the priorities:
- Description – more detailed than the name. The higher the priority of an item, the more important it is to work on making it less fuzzy and more of a deliverable, adding details.
- Acceptance Test – you can attach a formal acceptance test.
- Category – a categorization of the topic, for example “back office” or “optimization”. That way the product owner can easily filter out all “optimization” items and set their priority to low, etc.
- Components / Modules – Usually realized as “checkboxes” in the Excel document, for example “database, server, client”. Here the team or product owner can identify which technical components will be involved in implementing this backlog topic. This is useful when you have multiple Scrum teams, for example a back office team and a client team, and want to make it easier for each team to decide which items to take on.
- Requestor – the product owner may want to keep track of which customer or stakeholder originally requested the item, in order to give them feedback on the progress or in general for requirements tracking.
Remember that the backlog shall be visible to everyone but modified only by the product owner.