mirror of
https://github.com/netbox-community/netbox.git
synced 2025-07-22 12:06:53 -06:00
- Described the backlogs
- Described backlog refinement (WIP) - Refined backlog review (WIP)
parent
82fcb4d5b0
commit
ba57fb7f3c
@ -1,5 +1,32 @@
|
||||
This page describes the mechanics of a NetBox development cycle.
|
||||
It is a work in progress and always will be.
|
||||
This page describes the elements and mechanics of a NetBox development cycle.
|
||||
It is a work forever in progress.
|
||||
|
||||
# The Backlogs
|
||||
The universe of planned work to be done in NetBox, and the team's current set of work priorities, are represented in the Product Backlog and the Cycle Backlog, respectively.
|
||||
|
||||
## Product Backlog
|
||||
The Product Backlog captures the set of issues that are currently planned for completion in future releases of NetBox. The product manager is responsible for "gardening" this backlog, ensuring that each issue is appropriately detailed, estimated, and prioritized. The issues at the top of the Product Backlog ought to be the ready to make their way into the Cycle Backlog.
|
||||
|
||||
An issue in the Product Backlog needs to have the following custom field attributes:
|
||||
- Size (S / M / L / XL) – A rough estimate only
|
||||
- Target Release (e.g. `v4.0`, `v4.1`, `v4.2`)
|
||||
|
||||
In most cases, the sizing and targeting will be somewhat fuzzy for an issue near the bottom of the Product Backlog. As an issue moves toward the top, these attributes come into sharper focus.
|
||||
|
||||
## Cycle Backlog
|
||||
The Cycle Backlog comprises the set of issues that make up the team's focus for the current cycle. It is fed from the Product Backlog through a continuous refinement process.
|
||||
|
||||
An issue in the Cycle Backlog needs to have the following custom field attributes:
|
||||
- Size – Expected time for an appropriate developer on the team to complete work on the issue
|
||||
- S: Half-day or shorter period
|
||||
- M: Up to two days
|
||||
- L: Inside one week
|
||||
- XL: Two weeks
|
||||
- With very rare exception, XL issues must be broken down into smaller issues before entering the Cycle Backlog
|
||||
- Category (e.g. _Core_, _Deprecations_, _Feature_, _Miscellaneous_, _Plugins_)
|
||||
- Priority (1 through 5, where 5 is highest priority)
|
||||
- Target release (also migrated to _Milestone_ issue field)
|
||||
- Status (_Backlog_, _Todo_, _In Progress_, _Done_)
|
||||
|
||||
# Ceremonies
|
||||
The core team meets in a daily standup. Whenever possible, the following ceremonies are fit into that 30-minute slot.
|
||||
@ -8,11 +35,20 @@ The core team meets in a daily standup. Whenever possible, the following ceremon
|
||||
Each team member answers three questions:
|
||||
- What did I work on previously?
|
||||
- What will I work on today?
|
||||
- Is anything blocking my work?
|
||||
- Is anything blocking my work on an assigned issue?
|
||||
|
||||
## Backlog Review
|
||||
On the first day of a new cycle, the team conducts a backlog review.
|
||||
The purpose of this ceremony is to select issues from the cycle backlog for work during the new cycle.
|
||||
## Cycle Backlog Refinement – Last day of every other cycle, as needed
|
||||
The product manager and the developers refine the issues in the Product Backlog so that they make progress toward the Cycle Backlog.
|
||||
|
||||
Starting at the top of the Product Backlog, the team selects issues that they collectively agree are ready to work during the cycle about to begin, or the one immediately following. Each candidate issue is subjected to thw following prompts (`TODO`: transform this to a flowchart)
|
||||
- Are we confident in the sizing? Refine if necessary.
|
||||
- Which category fits the issue?
|
||||
- What should be the issue's priority?
|
||||
- Does the issue have a _Milestone_ that matches its _Target Release_? If not, make it so.
|
||||
- Set the issue's _Status_ to _Backlog_
|
||||
|
||||
## Cycle Backlog Review – First day of every cycle
|
||||
The product manager and the developers review the cycle backlog, selecting issues from the cycle backlog for work during the new cycle.
|
||||
|
||||
Each issue in the cycle backlog goes through a process that subjects it to one of four fates:
|
||||
- Remain in the cycle backlog
|
||||
@ -20,7 +56,7 @@ Each issue in the cycle backlog goes through a process that subjects it to one o
|
||||
- Assign and promote to Todo
|
||||
- Break down into smaller issues
|
||||
|
||||
In chart form:
|
||||
In chart form (`TODO`: Add a bit more granularity upstream of _Any Takers?_):
|
||||
```mermaid
|
||||
flowchart TD
|
||||
A[🎬
|
||||
|
Loading…
Reference in New Issue
Block a user