Discover ordered list, simple, improving, start when sufficient stories defined , importance value, higher items at the top, work estimate
Product Backlog: ordered list of stories.
Product Backlog description:
- The Product Backlog is an ordered list of everything that might be needed in the final product of the project (a wishlist of the expected final product).
- All items are described in simple business language (non-technical) and all of them are presentable to every stakeholder.
- Every requirement and every change in the project will be reflected in the Product Backlog.
- The Product Backlog is dynamically changing and improving; it is never complete.
- The first Sprint can be started as soon as the Product Backlog has a sufficient number of stories defined and we do not wait until the Product Backlog is complete to start delivering the items
- The Product Owner sets a number of factors (ROI) to determine the value of each item for the business, summarized into one importance value shown with each item.
- The Product Backlog items are ordered based on their value, with the higher items at the top so it will be sooner delivered by the Development Team.
- Top backlog items should be clear and detailed.
- Each Product Backlog item should have a work estimate completed by the Development Team, to determine the team’s capacity for a given Sprint (number of items that could be completed).
Information available for a single Product Backlog item in a typical Scrum tool like JIRA include:
- Story Name: the user story itself e.g. "As a user I want to login to my account to get access to my data"
- Story Description: all the relevant information about the story so that the whole Scrum Team can have access to it.
- Story Complexity: defines the nature of the story and used for Sprint Planning (usually the more complex a story is, the more uncertain its estimate would be)
- Story Estimate: estimated volume of the story determined by the Development Team.
- Assignments: story can be assigned to any person in the team (even if whole Scrum Team would remain accountable for it)
- Tasks: breakdown the story into tasks (detailed planning) and track them separately.
- Comments: each member of the Scrum Team can leave comments and collaborate with others
- Categories: easy way to ease of access and maintenance when multiple stories in the backlog (act as a normal WBS)
- Colours: You can set different colours to each story to differentiate them visually in the Scrum board. This is another way of grouping/categorizing items.
- Tracker: You can record time spend on each story for further analysis, refining estimates, billing, etc.
- Attachments: attach relevant documents and use the software as a document management tool.
- Alerts: optional custom alerts can be set here
- Due Date: optional custom due dates to track stories
- custom fields
NOTE: Collaboration features are more important when the Scrum Team is not co-located and traditional ways of collaboration are not possible.
Product Backlog process guidelines:
- The Scrum Team should add details, estimates, and order to the Product Backlog items all the way through the project, which is called Product Backlog grooming and it should not consume more than 10% of the time of the Development Team.
- The Product Backlog is created more based on discussion rather than documentation.
- The Product Backlog items (aka stories) should be easy to understand for non-technical stakeholders.
- It is common to break the large stories into two or more stories later.
- There should be only one Product Backlog, no matter how many Scrum Teams are working on the project, as the Backlog is a representation of the scope of the final product.