After creating and saving a Scrum-type project, Nutcache automatically generates an artifact called the "Backlog management". Use this artifact to build your product backlog.  




REMINDER
What is a product backlog? A product backlog is a prioritized list of both functional and non-functional client requirements derived from and in accordance with the project final goal. Simply put, it's a list of things that need to be done within a project.



Defining personas

In order to attain and achieve the product goal based on the client or stakeholders (sponsors) requirements, it is important to identify and detail all the users involved in the final use of the product. This step consists in defining personas.


A persona is an archetypal user, a fictional representation of target users you can use to help guide decisions about product, features, design, etc. Stories from the Personas list therefore represent fictional characters created to represent the attributes of a group of users. Once accepted, these stories can be moved to the Backlog list by a simple drag and drop action. Personas allow you to define very precisely user profiles by including:


  • age 
  • socio-economic backgrounds 
  • field of activity habits 
  • how the user will use the system 
  • how often the user will use the system 
  • business value 
  • etc.


Once all the personas are defined and added to the default "Personas" list, it is much easier to define the features to develop (the stories) to meet the product goal.


Creating and adding stories to the backlog

After setting the product goal and defining the main personas, the next step is to create and add stories to the Backlog list. Building the backlog is collaborative operation as it involves the Product Owner and the development team. The backlog is not a fixed document; if needed, new requirements are added and existing requirements may be modified, defined in more detail or even deleted.


Click the +Story link to create a new story:




The first tab lets you enter a description for the story, or in other words, describe the task that needs to be performed.



Then, completed the following fields:

  • Business value: Each entry in the product backlog must have some kind of business value for the client. The higher the business value of a story, the greater its priority will be when time comes to prioritize stories.
  • Complexity: The complexity scale, based on the Fibonacci sequence, helps estimating the workload to be performed.
  • Return on investment: The ROI of a story is obtain by dividing the business value of a story by its complexity level.


The remaining fields will be addressed when assigning stories during the course of the Sprint.

  • Estimated time: The estimated time it will take to complete the story
  • Actual time: Represents the exact number of hours logged on this story through time entries.
  • Project item: Link the story to an existing project item (a project task) in order to track time and affect project budget.
  • Planned start date: The story planned start date.
  • Planned end date: The story planned end date.
  • Start date: The story actual start date.
  • Done date: The date the story is completed.



The other tabs from the story dialog box will also be addressed during the course of the Sprint.


Prioritizing the stories

All stories must be prioritized and the product backlog ordered. The Product Owner does the prioritization. The business added value is one of the most common factors for prioritization. Moreover, dividing the business value of a story by its complexity level gives you the ROI of a story, which is a valuable information when it comes to prioritize the work that needs to be performed.



The Sandbox

Stories in the Sandbox list represent a backlog of suggested stories. See the Sandbox as the waiting room where you add ideas to validate and possibly include on the product roadmap. Once accepted, these stories can be moved to the Backlog list by a simple drag and drop action.


The Icebox

Stories in the Icebox list represent a backlog of things that you’re not going to work on any time soon, but you might want them in the future. Usually made up of low priority bugs and even low value features, which are commonly requested. Once accepted, these stories can be moved to the Backlog list by a simple drag and drop action.



Now that the product backlog is finalized, the next step consists of creating and launching the first sprint.