As you probably know, every team needs to capture requirements at some point for the product or service they are working on.
In Agile Scrum we do this using a Product Backlog.
The Product Backlog is an ordered list of everything that is known to be needed in the product.
By popular demand, please see below an example product backlog. This is for a mythical sports website.
It shows the product vision. Then the vision turned into epics, prioritised, estimated and refined for sprint 1.
Sports Website Vision
Notes:
- The overarching vision is captured on the board above.
- It clearly states that sports fans of all ages are the intended website users, particularly for the top sports in the world.
- It provides three explanations about why the sports fans would like to use the website, the key product features, and the business goal and how the business model might perform in the future.
- As you may have noticed, the info on my vision board is concise and coarse-grained.
- On one hand, we’re able to understand the new site’s market, value proposition and its business model using the Vision Board above.
- On the other hand, due to its many untested assumptions, using the board to develop the product backlog would be quite a risk.
- What we need is to point out and validate its assumptions systematically.
Notes:
- the BBC Sports Website has been used as an example here.
- There is a Content Management System (CMS) being used to publish content on the site.
- all the items are considered epics until they are broken down further.
- a lot of the acceptance criteria is vague and not tied down.
- a small phrase in caps such as SPORTS HOMEPAGE has been included in the epic title. This can later be used to group user stories into a ‘theme’.
Notes:
- The Product Owner (PO) has decided that getting the football (soccer) home page done early is of higher value to the business than the other sports because it is the most popular sport in the world according to research.
- Similarly the Navigation Menu is higher value to get done early, because without it, the site cannot be navigated
- The other sports home pages are similar to football and therefore should be easier to build after the football page has been completed
- The PO has decided that the sports pages, navigation, story and video pages form the core of the site and meet the business vision in a worst case scenario.
- Advertising is important, but revenue is a goal for another release, so the business would launch without it if push came to shove. This release is about brand awareness!
Notes:
- Most of the epics have high estimates of 40 or 100. This can be because we are in the early stages of the product and criteria is vague. Also because there is alot to do due to the effort required to build a CMS and a website.
- The Navigation story is much smaller than the others meaning it is less effort. It has been called an epic for now because the team do not know if they can accomplish it in a sprint. We will think about that in another product backlog refinement meeting (coming up later in this class).
Notes:
- The stories highlighted in yellow are no longer epics. They have been split if necessary and refined to a size that can be completed by the team in one sprint
- In this case, the CMS aspect of each story has been separated out into it’s own story. This was a team decision. However usually I like to keep back-end and front-end tasks in one story where possible for end-to-end testing reasons. This is not always easy.
- Related stories have been grouped using the phrase in caps. This is known as a “theme”.
- The 20 point stories still may be too large for the team to finish easily in a sprint. They may want to break them down further in another refinement meeting.
- The team now have enough to take at least one or more stories into a sprint planning session.
- Further backlog refinement meetings can be used to break down the remaining epics or even further break down the stories..