The product backlog really encapsulate your high-level product vision to all people participating in the product's development life cycle. So what is the definition of a product vision? It is: what is the objective of the software product, what is the features offered by the software product, what is the roadmap of the software product, what will we focus on next during the product development, what is the business value of features on the product backlog, what else besides functionality features needs to be delivered to make the product)
I would say it is important to put in effort to write proper stories on the product backlog, using the right format for writing these stories, as it will save you time and money later in that: 1. people have a better understanding of the feature, 2. You do not have to redo the feature later into a proper format, 3. functionality and all related tasks needed to deliver the software is communicated in a consistent way, 4. you started writing your spec already.
A proper story would look as follows:
| Feature: Write a product backlog |
| In order to build the ... software (business value) |
| As a ... Product Owner (role/user/system) |
| I want to pin down all the current high-level product features (requirement) So on the product backlog you will only have the details of the story. Scenarios will be made available for each sprint to the team as part of the sprint planning, to provide more detail on exactly what needs to be delivered. The scenarios will then be used to do estimation during sprint planning. A Scenario will look as follows: Given ... (input) And ... And ... When ... (event) Then ... (outcome) And ... And ... |
Download Product Backlog template: http://www.taniavanwykdevries.co.za/Downloads/ProductBacklogTemplate.xlsx
