Backlog Items

The product backlog consists of a prioritized list of work to be completed. At the beginning of a project, the Product Backlog Items (PBIs) are typically:

• Features to be added (User Story)
• Knowledge to be gained - time-boxed investigations to learn more about how best to approach an upcoming PBI (Spike)

As the project progresses, additional types of PBIs are introduced:

• Defects that should be fixed
• Technical rework

Technical rework is typically the result of cutting corners to complete an earlier PBI. Taking on technical debt is a legitimate part of Scrum, but it is critical that technical debt is tracked and addressed. Left unmanged, accumulated technical debt can introduce challenges that make completion of additional features painfully slow.

PBI Attributes

Fully developed product backlog items should:

• Briefly state the work to be accomplished
• Focus on business value
• Describe work that can be completed in one sprint
• Have clearly understood acceptance criteria
• Often written as a user story (As a [role], I want [goal/desire] so that [benefit])
• Assigned an effort in terms of "story points", not hours
• Have a priority describing its importance relative to other PBIs

File Format

Each PBI should be captured in a markdown file named [PBI#][2-4 word description].md and be placed in a subdirectory in .issues. The subdirectory it should be placed in depends on the state of the PBI.

• .issues/backlog - Planned for a future sprint
• .issues/open - Committed as part of current sprint
• .issues/closed - Closed (either completed or abandoned)

The file must begin with the following:

**Type:** [PBI Type]
**Priority:** [Priority]
**Story Points:** [# of points]
**Status:** [Status]

• PBI Type - one of: Feature, Defect, Spike, Debt
• Priority - unset when in backlog, set to [sprint#]-[priority] when added to a sprint. E.g., 2-1 means the highest priority item in the second sprint.
• Story Points - Use Fibinacci numbers or t-shirt sizes
• Status - Backlog, Open, Closed, Abandoned

This should be followed by several sections:

• TL;DR - one or two sentence summary
• Description - Summarizes the motivation for the PBI
• Acceptance Criteria
• Dependences (if any)
• Tasks - list of subtasks needed to complete the PBI
• Closing Notes - added when PBI is closed

Backlog Grooming

Throughout each sprint the backlog should be actively groomed (PBIs added and refined). The backlog should contain a mix of fully developed PBIs and more preliminary PBIs. At the beginning of each sprint there should be enough fully developed PBIs to fill at least one and a half sprints.

During sprint planning, the team should decide which PBIs will be added to the next sprint and create a list of tasks under each PBI that enumerate the tasks required to complete the PBI. These tasks should have time estimates associated with them. As a general rule, tasks should range in duration from 2 to 5 hours in length. Each PBI brought into a sprint should be completely fleshed out prior to the start of the sprint. During the sprint you may find the need to add or re-estimate tasks. That's bound to happen, but hopefully your team will find it happening less and less as the year progresses.

Example File

Filename: 0012 Calculate academic standing.md

**Type:** Feature
**Priority:** 2-3
**Story Points:** 2
**Status:** Open

# TL;DR
Enable an advisor to calculate academic standing.

# Description
As an academic advisor, I want to determine the academic standing of my advisee. Academic standing
is based on the number of credits successfully completed.

# Acceptance Criteria
- Given that the course history file for a student has been successfuly parsed, when the “Calculate academic standing” capability is used, then all credits are expressed in semester units before they are used in calculations or displayed in dashboard credit totals.
- Given that the course history file for a student has been successfuly parsed, when the “Calculate academic standing” capability is used, then quarter-based credits are converted to semester units by multiplying by 2/3.
- Given that the course history file for a student has been successfuly parsed, when the “Calculate academic standing” capability is used, then standing credits include: successful credits; WIP credits from terms before the advising term.
- Given that the course history file for a student has been successfuly parsed, when the “Calculate academic standing” capability is used, then standing is: FR below 30 credits; SO from 30 to below 60; JR from 60 to below 90; SR at 90 or more.
- Given that the course history file for a student has been successfuly parsed, when the “Calculate academic standing” capability is used, then removed requirements do not count.
- Given that the course history file for a student has been successfuly parsed, when the “Calculate academic standing” capability is used, then waivers do not count as earned credit unless explicitly configured otherwise.
- Given that the course history file for a student has been successfuly parsed, when the “Calculate academic standing” capability is used, then the calculation is unit-tested at each boundary.

# Dependencies
- Requires 0003 to be completed - done as of Sprint 1

# Tasks
1. Develop tests for acceptance criteria
2. Filter out courses that should not be included
3. Identify courses containing quarter-based credits and convert them to semester credits
4. Calculate sum and determine relevant cohort
5. Ensure all tests pass

# Closing Notes

When a PBI moves from .issues/backlog to .issues/open, tasks should be refined.