Northern SPIRIT

h1. Backlog Operations

This page outlines information relevant to the backlog and the generation of tasks.

Covered Topics:

* How to organize and use the backlog

* Why and when to add a story to the backlog

* How to create a story

* How to parent a story

h2. What is a Backlog and its purpose

*Definition* : A product backlog is a prioritized list of work for the development team that is derived from the roadmap and its requirements. The most important items are shown at the top of the product backlog (by assigning them the highest priority) so the team knows what to deliver first.

*It's purpose* : It's a reliable and shareable outline of the work items for a project.

Fostering discussion around what's important gets everyone's priorities in sync. These discussions foster a culture of group prioritization ensuring everyone shares the same mindset on the program.

The product backlog also serves as the foundation for spring (or iteration) planning. All work items should be included in the backlog: bugs, design changes, technical debt, customer requests, action items from the retrospective, etc. Each of these can be referred to as a *"user story"*. Maintaining an accurate list of user stories ensures everyone's work items are included in the overall discussion for each sprint. Team members can then make trade-offs with the product owner before starting a sprint with complete knowledge of everything that needs to be done.

h2. How to Organize and use a Backlog

The most important items are shown at the top of the product backlog so the team knows what to deliver first. The development team doesn't work through the backlog at the product owner's pace and the product owner isn't pushing work to the development team. Instead, the development team pulls work from the product backlog as there is capacity for it.

Typically, a Scrum team and its product owner begin by writing down everything they can think of for agile backlog prioritization. This agile product backlog is almost always more than enough for a first sprint. The Scrum product backlog is then allowed to grow and change as the project progresses.

Our Scrum backlog comprises the following different types of items:

* Features

* User Stories

By far, the predominant way for a Scrum team to express tasks on the backlog is in the form of user stories, which are short, simple descriptions of the desired functionality told from perspective of the user.

While the product owner is tasked with prioritizing the backlog, it's not done in a vacuum. Effective product owners seek input and feedback from customers, designers, and the development team to optimize everyone's workload and the product delivery.

*What can influence prioritization?*

* Client priority

* Urgency of getting feedback

* Relative implementation difficulty

* Symbiotic relationships between work items (e.g. B is easier if we do A first)

* Product Backlog items that can be Done by the Scrum Team within one Sprint are deemed ready for selection in a Sprint Planning event. They usually acquire this degree of transparency after refining activities. Product Backlog refinement is the act of breaking down and further defining Product Backlog items into smaller more precise items. This is an ongoing activity to add details, such as a description, order, and size. See [[Backlog_Grooming]] for more details.

h2. Why and when should I add a story to the backlog?

The backlog is where you keep all of the work items that your team is planning to tackle. Keeping the backlog up to date and organized is essential for team work flow. Any team member can add a user story or feature to a backlog. Usually, work items are added immediately after a meeting or a discussion via email or slack. If the matter is urgent, the work item is added to a current sprint, if the urgency is not immediate, then the work item is stored in a backlog and discussed with a team during a sprint planning meeting.

h2. How to Create a Story

Stories can be created via the Issues tab within the project. Once at the backlog, on the top menu bar there is an option to create a new issue.

!NewIssue.JPG!

Fill in all required fields, add a category and parent feature, and add other fields such as sprint, start/end date, and estimated time if known.

!NewIssue2.JPG!

h2. How to Parent (or edit in general) a User Story

Parenting stories is important to link the stories with features and be able to construct an accurate timeline. If you've created a task without a parent, add one by selecting the task and clicking Edit in the top menu.

!Parenting1.jpg!

You will see the following edit box appear. Type in the name of the feature which will be the parent task. Then click Submit at the bottom of the page to save.

!Parenting2.jpg!

Now on the task page you will notice that the parent task appears above the task name.

!Parenting3.jpg!

You'll also now notice that in the backlog, when the list is filtered such that the child task is immediately below the parent, there is an indent. Finally, in the default view, the parent feature can be seen in the Parent task column, and hovering over the link will show the feature name.

!Parenting4.jpg!