Review Solution Architecture

(Activity) for Tier: Sprint

PURPOSE

Reviewing solution architecture is intended to ensure code created during execution of a software development task conforms to the overall plan for implementing a feature and the overall system’s architecture. These designs reduce initial defects in the software and help ensure the software can evolve over time at lower cost and with a lower risk of introducing new defects.

WHEN

When a task(s) for development of new code, or change to existing code, have been assigned for implementation.

PARTICIPATING ROLES

ENTRY CRITERIA

  • Project’s solution architecture documentation has been updated as needed for the sprint.

SUB-ACTIVITIES

  1. Review Architecture Artifacts

    • All team members assigned to implement a development task must review architecture artifacts related to the functionality the task will enable before creating new code or altering existing code.
      • As needed review requirements documentation related to the function being implemented.
    • If a task implementer either does not understand the architecture or believes the task cannot be completed without changes to the architecture, they will update the work item assigned to them to show that work item is blocked by an architectural impediment in accordance with team procedures and notify the team at the next Team Stand Up Meeting. For this activity, teams are to mark the blocked work-item in a manner that supports historical reporting/measurement and analysis.

    Note

    AzureDevOps (2019) does not support querying deleted tags. Using only tags for tracking blocked work-items does not support the historical reporting criteria. Using a tag AND a linked issue work item can satisfy the historical reporting requirement, if the linked issue work item is used to track and manage the lifecycle of the raised architectural concern. Expected drivers for higher counts in this activity are new employees, new projects, technical refreshes, major changes to business requirements, changes to process guidance, or any other type of change.

  2. Resolve Architectural Impediments

    • Clear any work blockage resulting from the review of architecture artifacts. This may be done either by providing assistance and clarification to the team members who are blocked or by revising the architecture.

    • Provide an opportunity for blocked team members to voice concerns and/or seek clarification on the Solution Architecture. This only applies when current sprint execution is blocked. Otherwise concerns with the existing solution architecture should be voiced during the Identify Architectural Concerns activity.

    • Decide, in accordance with team norms, on the need to alter the existing solution architecture before completion of one or more work items included in the current sprint.

      • If the decision is that a change is not required to complete the work items, then ensure that the implementing team members receive whatever assistance is needed to successful accomplish the required work.
      • If a change to the architecture is needed execute the “Identify Architectural Concerns” activity.

    • Determine, in accordance with team procedures, what changes, if any, to schedules and priorities are needed.

OUTPUTS

Exit Criteria

  • Solution architecture artifacts have been reviewed by those implementing new code or code changes.
  • Any work blockages resulting from review of the architecture artifacts have been communicated to the team by updating the impacted work item.

See Also

Process Guidance Version: 10.4