Skip to content

Tracking the progress of the software architecture's design

Practice · Chapter 5

Tracking tells you how much design work is done and what remains, lets you prioritize what to do next, and reminds you of outstanding design issues so nothing slips. The exact technique depends on project, methodology, and organization — with Scrum, product and sprint backlogs are natural fits.

  • A product backlog lists all features and bugs. Consider a separate architecture-specific backlog holding design issues, decisions to be made, and architecture-specific ideas.
  • Flow: prioritize backlog items → sprint planning selects items for the sprint → selected items move to the sprint backlog → create and assign tasks → track → remove items when complete.

Prioritizing the backlog — DIVE criteria

Section titled “Prioritizing the backlog — DIVE criteria”

Prioritization isn’t one-and-done; revisit it whenever the backlog changes. Items should be linearly ordered. One proven prioritization scheme is DIVE:

LetterCriterionMeaning
DDependenciesItems others depend on come first (if A depends on B, B ranks higher).
IInsure against risksWeigh business and technical risk; risk may raise or lower an item’s priority.
VBusiness valueHigher-value items (judged with stakeholder input) tend to rank higher.
EEstimated effortScheduling/resource factors; a large item may be pulled forward to ensure it finishes in time.

The architecture backlog evolves as design iterations complete. Items get added when new architectural drivers emerge, when reviews reveal problems, or when a decision spawns new concerns (e.g. choosing a web application adds security, session-management, and performance items). Such changes may prompt re-prioritization.

Audience: make the backlog available to those who need visibility into progress. Architecture and project backlogs may have different audiences — clients might see the product backlog to track functionality while the team keeps the architecture backlog private, depending on the project’s level of transparency.

  • Software Architect’s Handbook (Packt, 2018), Ch.5 “Tracking the progress of the software architecture’s design”, pp. 383-391.