Skip to content

Development Cycle

Jump to bottom
Jeff Gehlbach edited this page Jun 25, 2024 · 5 revisions

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.

Main Standup

Each team member answers three questions:

  • What did I work on previously?
  • What will I work on today?
  • Is anything blocking my work on an assigned issue?

Bug Blitzes

Bug blitzes are periods during which the team suspends all planned feature work to focus exclusively on bugs.

The team may declare a bug blitz any time the count of open issues with a severity assessed exceeds 50. The blitz ends when that figure drops to 40.

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 property in the project to Backlog

Cycle Planning – First day of every cycle

The product manager and the developers review the cycle backlog, selecting issues from the Backlog column for work during the new cycle, confirming their readiness, and ideally moving them to the Todo column.

Each issue in the cycle backlog goes through a process that subjects it to one of four fates:

  • Remain in the cycle backlog
  • Regress from cycle backlog to product backlog
  • Assign and promote to Todo
  • Break down into smaller issues

In chart form:

flowchart TD
    A[🎬
    Start] -->B[🎟️
    Backlog Column]
    B -->C{✋
    Any Takers?}
    C -->|Yes| D{🤔
    Achievable
    in 1 Cycle?}
    C -->|No| E{🤔
    Still a Fit
    for Milestone?}
    E -->|Yes| H[🏁
    Keep in
    Cycle Backlog]
    E -->|No| I[🏁
    Remove to
    Product Backlog]
    D -->|Yes| J[🧑‍💻
    Assign]
    J --> F[🏁
     Promote to Todo]
    D -->|No| G[🧩
    Break Down
    into Smaller Issues]
    G -->B
Loading

Retrospective

At the end of a cycle, the team may opt to hold a lightweight retrospective in which the team collaboratively answers the following:

  • What worked well this cycle?
  • What could have worked better?
  • What should we change going forward?
Clone this wiki locally