Northern SPIRIT

h1. Backlog Operations

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

Covered Topics:

* What is a backlog and it's purpose

* How to organize a backlog

* Hierarchy of the backlog

* How to create a story

* How to create a task

* How to parent a story

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

* Updating the backlog 

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 more is learned about the product and its customers.

Our Scrum backlog comprises the following different types of items:

* Features

* User Stories

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

The product owner shows up at the sprint planning meeting with the prioritized agile product backlog and describes the top items to the team. The team then determines which items they can complete during the coming sprint. The team then moves items from the product backlog to the sprint backlog. In doing so, they expand each Scrum product backlog item into one or more sprint backlog tasks so they can more effectively share work during the sprint.

Conceptually, the team starts at the top of the prioritized Scrum backlog and draws a line after the lowest of the high-priority items they feel they can complete. In practice, it's not unusual to see a team select, for example, the top five items and then two items from lower on the list that are associated with the initial five.

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?

Backlog is where you keep all of the work items that your team is planning to tackle. Keeping 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 retrospective.

h2. How to Create a Story

Stories can be created via backlogs. Once at the backlogs, on the top menu bar there is an option to create a new work item.

[TBC]

h2. How to Parent a Story

Parenting stories is important to link the stories with features and be able to construct an accurate timeline.

[TBC]

[[Sprint_Operations]]