Wiki¶

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

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 so the team knows what to deliver first.

It's purpose : It's a reliable and sharable 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 iteration planning. All work items should be included in the backlog: user stories, bugs, design changes, technical debt, customer requests, action items from the retrospective, etc. This ensures everyone's work items are included in the overall discussion for each iteration. Team members can then make trade-offs with the product owner before starting an iteration with complete knowledge of everything that needs to be done.

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.

A typical Scrum backlog comprises the following different types of items:

• Features
• Bugs
• Technical work
• Knowledge acquisition

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.

Because there's really no difference between a bug and a new feature -- each describes something different that a user wants -- bugs are also put on the Scrum product backlog.

Technical work and knowledge acquisition activities also belong on the agile backlog. An example of technical work would be, "Upgrade all developers' workstations to Windows 7." An example of knowledge acquisition could be a Scrum backlog item about researching various JavaScript libraries and making a selection.

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?

Customer 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. Attributes often vary with the domain of work.

The Developers who will be doing the work are responsible for the sizing. The Product Owner may influence the Developers by helping them understand and select trade-offs. Multiple Scrum Teams often work together on the same product. One Product Backlog is used to describe the upcoming work on the product.

Keeping the backlog healthy

Once the product backlog is built, it's important to regularly maintain it to keep pace with the program. Product owners should review the backlog before each iteration planning meeting to ensure prioritization is correct and feedback from the last iteration has been incorporated. Regular review of the backlog is often called "backlog grooming" in agile circles(some use the term backlog refinement).

Once the backlog gets larger, product owners need to group the backlog into near-term and long-term items. Near-term items need to be fully fleshed out before they are labeled as such. This means complete user stories have been drawn up, collaboration with design and development has been sorted out, and estimates from development have been made. Longer term items can remain a bit vague, though it's a good idea to get a rough estimate from the development team to help prioritize them. The key word here is "rough": estimates will change once the team fully understands and begins work on those longer term items.

The backlog serves as the connection between the product owner and the development team. The product owner is free to re-prioritize work in the backlog at any time due to customer feedback, refining estimates, and new requirements. Once work is in progress, though, keep changes to a minimum as they disrupt the development team and affect focus, flow, and morale.

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.

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]

Sprint_Operations