Building a backlog from a functional perspective involves identifying and organizing the features, user stories and requirements. To build up a backlog the following actions are needed:

  • Gather requirements in alignment with the stakeholders
  • Break down high-level features into smaller, actionable user stories
  • Prioritize user stories based on business requirements
  • Define acceptance criteria
  • Estimate

The backlog building is an evolving activity, the backlog changes over time, during the project the Success Manager needs to take care of the relevancy and accuracy in alignment with the business and development team.

Note

OSB relies on Azure DevOps, which is an Agile project management tool for software development projects.

Azure DevOps terms

AREAS:

Areas in Azure DevOps represent the different functional or organizational areas within a project. Areas help categorize and group work items based on their respective functional or organizational areas. This provides better visibility and clarity on the overall project structure.

ITERATIONS:

Iterations in are timeboxes used to plan and track work during a specific period, often referred to as sprints. Iterations focus on delivering a set of prioritized work items within a defined timeframe. The length of a Sprint is defined by the team and technology approach - based on standard agile methodology a Sprint used to be 2 weeks long.

Backlog items

EPIC

An epic represents a large and high-level body of work that encapsulates a significant and strategic functionality or initiative within a software system. Epics provide a way to organize and prioritize development efforts and can be further broken down into smaller, manageable features or user stories. A well-defined DevOps epic description helps the development team understand the functionality, define related features, and guide their development efforts effectively. A DevOps epic description should provide a high-level overview of the functionality and its goals. An epic can be a system module or a whole app itself.

FEATURE

A feature refers to a cohesive and self-contained functionality, it represents a larger piece of work that delivers value to the end-users or stakeholders. A feature description should provide a clear understanding of the functionality and its purpose.

It should contain the following elements:

- Title: A concise title that summarizes the feature.
- Description: A detailed description of the feature's functionality, outlining what it does and why it is important. It should provide context and explain the problem or need it addresses.
- Acceptance Criteria: Define the conditions or criteria that need to be met for the feature to be considered complete. These criteria should be specific, measurable, and testable, enabling the development team to validate the functionality.
- Dependencies: If the feature has dependencies on other features, systems, or components, it is important to document them. 
- Non-Functional Requirements: Specify any non-functional requirements or constraints related to the feature, such as performance, security, scalability, or compliance.

USER STORIES

A user story is a concise, customer-centric description of a functionality. It focuses on the desired outcome and the benefit it brings rather than the technical implementation details. A well-written user story helps the development team understand the functionality, define related tasks, and align their efforts.

A DevOps user story typically follows the "As a role, I want goal, so that benefit" format.

Each part should contain the following:

  • Role: Identify the role or persona of the user who will benefit from the functionality. This could be an end-user, system administrator, developer, or any other relevant stakeholder.
  • Goal: Describe the specific goal or action the user wants to achieve. It should be clear and focused on the desired outcome. Avoid specifying the technical solution or implementation details.
  • Benefit: Explain the benefit or value the user expects to gain from achieving the goal. This helps provide context and prioritize the user story's importance.

User story writing guidelines:

  • Clear and Specific: The user story should be clear, concise, and specific, leaving no room for ambiguity. It should communicate what the user wants to accomplish and why it's important.
  • Testable: A good user story is testable, meaning it can be validated or verified to ensure it has been successfully implemented. The acceptance criteria, which define the conditions for the user story to be considered complete, should be included.
  • Independent and Atomic: Each user story should be independent and self-contained, addressing a single functionality or requirement. This allows for better prioritization, estimation, and incremental development.

TASK

A task refers to a specific unit of work or activity that needs to be performed as part of the development and delivery process. It represents a discrete and actionable item that contributes to the overall development, deployment, and operations of an application. The optimal granularity of a task:

  • Estimation should be between 1 and 8 hours:
    1. If it's more than 8 hour, task should be split to smaller ones
    2. If it less than an hour, more task should be merged
  • A task shall have only one responsible, if a collaboration needed to complete a chunk of work, that should appear as more tasks

In case of a Task the DevOps item needs to contain the following:

  1. Detailed description of the work needs to be done
  2. Guidelines for development testing of the functionality

A task is added and estimated by the solution architect together with the developers.

BUG

A bug refers to an error, flaw, or defect that causes it to behave unexpectedly or produce incorrect or unintended results. Bugs can manifest as functional issues, crashes, performance problems, or other unexpected behaviours that deviate from the intended functionality of the software. Bugs can have varying levels of impact, ranging from minor inconveniences to critical failures. A bug should be reproducible, meaning it can be consistently triggered or observed under specific conditions or actions.

In case of a Bug the DevOps item needs to contain the following: 1. Detailed description of the reproducing steps including user role, permission 2. Current behaviour 3. Expected behaviour 4. Acceptance criteria for fixing

A bug can be added by developer (during dev testing) and functional tester (during functional testing).

How to write the acceptance criteria

Writing effective acceptance criteria is crucial for ensuring a shared understanding between stakeholders and the development team regarding the expected behaviour and completion criteria of a feature or user story.

An acceptance criteria description is good enough when it's written with the following mindset:

- Specific and measurable: Clearly defines the expected behaviour of the feature in a specific and measurable way. Avoid ambiguous or vague language. Use concrete examples and precise conditions that can be objectively verified.
- Focusing on User Value: Acceptance criteria should reflect the value the feature delivers to the end-user. Emphasize the desired outcomes and benefits, rather than technical implementation details.
- Testable: Ensure that the acceptance criteria are testable. They should guide the creation of tests that can determine whether the feature meets the defined criteria. Consider including specific test cases or scenarios that can be used for validation.
- Covering Different Scenarios: Anticipate various scenarios and edge cases that the feature needs to handle. Consider both normal and exceptional situations to ensure comprehensive coverage. 
- Non-Solution Specific: Acceptance criteria should focus on the "what" and "why" of the feature, rather than dictating a specific solution or implementation approach. Avoid specifying technical details or user interface elements unless they are critical to the acceptance criteria.
- Prioritizing Essential Functionality: Focus on the most critical and essential aspects of the feature in the acceptance criteria. This helps ensure that the core functionality is clearly defined and can be delivered first, providing value to users as early as possible.

When writing acceptance criteria involve relevant stakeholders, including product owners, developers, and testers. Collaborative discussions help refine and validate the criteria, ensuring a shared understanding and agreement. Acceptance criteria may evolve as the team gains more insights so review and refine them throughout the development process to ensure they remain relevant.

The definition of done

- If you are a Developer: The implementation has been done with simple dev testing.
- If you are a Solution Architect: The implementation has been reviewed so the task can be closed.
- If you are a Success Manager: The implementation, code review has been done and the functional tests passed successfully.

Status transitions during the implementation

Status description

New: The task is appearing in the sprint as a "to-do" but it's not started yet. Active: The task you are working on. On Hold: The task can't be accomplished, continued because of lack of information or any other technological blockers beyond the developer's responsibility and/or capability. As a Developer to resolve an on-hold task do the following depending on the type of the blocker: - If the blocker is coming from lack of information: contact Success Manager - If the blocker is coming from technical difficulties: contact Solution Architect Resolved: The implementation with development testing is done. Closed: The implementation was done and the code review was successful.

User story status transitions

graph LR
    New[New] --> |Work started <br>on child Tasks |Active[Active]
    Resolved --> |Review completed successfully <br>on all child Tasks| Closed[Closed]
    Active -->|Implementation <br>AND<br> DEV test is completed <br>on all child Tasks| Resolved[Resolved]

Task and Bug status transitions


graph TD
    New[New] --> Active[Active]
    Active --> |More Info is needed<br>OR<br>technical blocker exists| OnHold[On Hold]
    OnHold --> |Info received<br>OR<br>technically unblocked| Active
    Resolved --> |Adjusment needed<br>based on Review| Active
    Resolved --> |Review Passed| Closed[Closed]
    Active -->|Implementation <br>AND<br> DEV test is completed| Resolved[Resolved]