How-to Work with Features

This guide describes how to handle features in streams. It includes examples of feature descriptions and information about the feature definition, grooming, and change management.

For further information about features and other requirements, see Requirements Structure.

Intended for

Product owners, architects, scrum masters, release owners, and product managers.

Activities

Create

Create features based on the epic description and assign them to development teams. Each feature should only be assigned to one development team – features cannot be shared between teams.

Add initial information to the feature work item, including:

• "Title": A concise name that provides understanding and context.
• "Owner": Must be set to the responsible scrum master for the feature.
• "Area": Must be set to the release/product where the feature will be delivered.

Refine and estimate

Organize refinement meetings (e.g. weekly) between the product owner and teams to secure a successful transfer from epics to features. A feature shall be implemented in one increment. Split the feature if it is too large or if appropriate smaller slices of functionality exist. The split shall make sense, avoiding the “Part 1 and Part 2” solution.

Analyze and refine the feature and its implications for the architecture and design.

The following fields are mandatory in the feature work item:

• The "Description" shall contain a benefit hypothesis, and a proposed measurable benefit to the end-user or business. It shall also contain details necessary to perform further refinement and implementation. To make the description more precise, clarify what is not included. Limitations may pertain to functionality, operating systems, services, etc. Initial ideas on implementation should be documented under "Details" with text or links to other material, such as an implementation proposal.

  Note: Avoid defining features with "user story voice" format. It is designed to support one user role, while features typically provide functionality for multiple user roles. Furthermore, a feature often implements a component and not a full functional vertical. A benefit hypothesis typically takes the form of “By [doing this], [these customers] will [achieve this benefit].

• The "Acceptance Criteria" defines the requirements that must be met and verified for feature acceptance. Typically, 3-5 criteria are adequate. The acceptance criteria are preferably documented in Gherkin syntax: Given <initial context> When <event> Then <expected outcome>. This ensures clear definitions and facilitates test case automation. Another alternative is to use statements like "It shall be possible to <criteria 1>".

  Note: There is a difference between acceptance criteria and definition of ready (DoR), and it is not OK to define the acceptance criteria as "Consider DoR".

  • Acceptance criteria: Criteria for content, different for each work item.
  • DoR: Criteria for processes, the same for every work item type.

• The estimation of "Effort" shall cover all work related to the feature (e.g. design, development, test, and documentation). Estimation is done in two steps:

  • The initial feature estimate is set on the draft feature during epic investigation (maximum one increment). This is a high-level estimate either done by points or expected effort (Azure DevOps requires that hours are filled in). Each release needs to set a common approach.

  • Refine the estimate when the feature is prepared for "Definition of Ready". This new estimate should be based on the draft user story estimates.

    Below is an example of a table comparing the alternatives:

  Points	Hours	Man weeks	Comment - example of what it could be in reality
  1	60	2	E.g. 1 team member for 2 weeks.
  2	120	4	E.g. 1 team member for 4 weeks.
  3	180	6	E.g. 1 team member for half increment (~6,5 weeks).
  5	300	10	E.g. 1 team member for most of increment (~13 weeks).
  8	480	16	E.g. 2-3 team members for half increment (~6,5 weeks).
  13	780	26	E.g. 2 team members for full increment (~13 weeks).

  Note: Remember that even if you use points when doing estimates for features, they must be translated to hours when entered into Azure DevOps.

• "Iteration path" shall describe in which increment the feature will be ready. When a feature is under preparation, this field can be left empty, but it shall be filled out no later than when it is set to “Active”.

• The “Value area” under “Classification” defines the type of feature and can be set to:

  • "Business": Based on system requirements, has a value for the customer.
  • "Architectural": Feasibility studies, technical evaluations, architecture updates, etc.
  • "UX": For UX related efforts.
  • "Intellectual Property": for IP related efforts.
  • "Enabler": Supports the implementation of business epics and administrative tasks.

• "Security Relevant", consider if it is likely that work will affect a security-critical component, as listed (already or to be) in the security criticality analysis, modify a component’s attack surface, or if the work in some other way security-relevant (this may motivate a revised criticality analysis). Some examples are modifications in functionality for authentication, access control, integrity checking, encryption, or protection measures for denial of service (DoS) attacks. The field can be set to:

  • "True" = Feature is security-relevant.

  • False = Feature is not security-relevant.

    If a feature is defined as security-relevant a "security-relevant argument" must be filled out (in the dedicated field). E.g. “The feature involves updating component xxx which has been defined as security critical” or “The feature scope includes remote access/back up/input validation/…”.

    See further details in the Security Criticality Analysis guide.

• Identify any dependencies. Under "Related Work", link the epic (parent) and user stories (children), including architecture, development, enabler(s), user experience, and test features. Link any work item, using predecessor or successor if dependencies affect implementation order.

  Note: Every feature shall be linked to an epic. In addition, some fields are not mandatory, e.g. priority, risk, business value, time criticality, and start/target date.

Approve and rank

Ensure that the feature contains all the necessary information for implementation and verification, and that key stakeholders agree to the estimate. The feature must meet the criteria outlined in the DoR of the feature work item:

• Understandable "Title" and "Description".
• Testable acceptance criteria established.
• If/how to demo defined.
• The feature is estimated to ensure it can be completed in an increment.
• Preliminary design ready.
• Draft user stories (including design and documentation).
• Link to epic.
• Dependencies on other features defined.
• The area and iteration path is set.
• Security impact considered.
• The feature is ranked in the backlog.

When the scrum master has provided all relevant information, "Assigned to" is set to the product owner, who will go through the DoR. The product owner reviews the feature and after approval returns "Assigned to" to the scrum master to indicate that the feature is ready for implementation.

Rank the feature by comparing it to other approved features in the team backlog. Drag-and-drop features in Azure DevOps to do the ranking.

Monitor implementation and test

Conduct regular team sync meetings with key stakeholders (product owner, architect, development team) to monitor feature progress, refine future features, and adjust their priorities and rankings.

Once the DoR for the feature is met and the first child is set to “Active”, the product owner or scrum master shall set the state of the feature to “Active”.

The product owner or scrum master is responsible for checking that the feature is kept updated (state, iteration path, etc.)

Component test cases to verify the feature shall be developed in parallel with the implementation of user stories. The feature's acceptance criteria serve as input to the test cases. Typically, these tests are automated. Create a user story under the feature to follow up on the feature's test activities.

For details about feature testing, see the Component Test Overview guide.

When all user stories are completed, including that tests are completed, the bugs are resolved, and all documentation is in place, the product owner or scrum master shall set the feature state to “Resolved”.

If the feature needs to be paused (e.g. due to changed product manager priorities, delayed delivery of dependent functionality, or unveiled technical uncertainties), the following shall be done:

• Set the feature's state to “New” with the reason “Implementation halted”.
• Update the iteration path to the agreed-upon new iteration or without a defined iteration if it is not yet set.
• In the discussion field, elaborate on the reason to pause and describe how far the work has proceeded.
• Ensure that linked child work items that are not yet closed have been managed in the same way.
• Ensure that dependent features are informed.

Review and close

When all work has finished with a feature, and all underlying user stories are set to “Closed", the product owner initiates closure.

Review the fulfillment of the definition of done (DoD) and involve relevant stakeholders.

• All child stories are closed.
• All unit and component tests passed.
• Component documentation approved (e.g. design and component capabilities).
• Demo performed (or planned).

Once the feature's DoD is met, change the state to “Closed.”

Details

Characteristics of features

Features represent a significant initiative with the following characteristics:

• Business value: Features should drive business value by adding or modifying a specific functionality, one of several parts needs to meet a business goal.

• Size and scope: A feature is implemented by one team during a maximum of one increment. It typically involves one component, but in a few cases the feature implements a container consisting of multiple components.

• Completeness: A feature should be well-defined and comprehensive, with clear boundaries and deliverables, while minimizing dependencies. It should encompass all necessary work, from initial analysis, development, test, integration, and documentation.

• Clarity: A feature must be articulated clearly, describing what is included/excluded and its acceptance criteria, and link to the epic it provides part of the solution to. This ensures that all stakeholders share a common understanding of the feature’s goals and expectations.

• Testability: Features should be designed to allow for thorough testing. The acceptance criteria must consider how the units are integrated into components and tested, see Component Test Overview.

Feature example

Below is an example of an feature with some of the key fields highlighted:

Feature change requests

Changes to features that impact a system requirement shall be driven through a change request in Decision Focus and replicated to system epics and lower-level work items.

Changes to features not impacting system requirements shall be handled without a change request as follows:

• Before DoR: Updates by product owner, scrum master or architect (inform development team and product manager).
• Between DoR and DoD: Updates jointly by product owner, architect, and development team (inform product manager).
• After DoD: No changes are allowed; create a new feature instead.

Note: Changes during an ongoing increment must be minimized. Excessive changes after the increment plans are committed decrease the team's performance. The teams need to focus on fulfilling their commitments in the increment.

Features grooming

Refinement or grooming is an essential part of managing features. This activity ensures that features are continuously updated, prioritized, and detailed as necessary. The main focus of grooming is on the upcoming increment.

There is a significant effort in grooming when technology investigations and architecture updates are considered.

The grooming is capacity-based, i.e., the capacity for key roles involved in grooming (product managers, product owners, architects, etc.) is limited to accommodate grooming activities.

See Requirements Structure for details on how features are refined during increments.

Feature state diagram

Note: A feature can be canceled at any time. This is done by setting the children's state to "Removed", and then the feature’s state to "Removed". Cancel all implementation, test, and verification work and store intermediate results for future use.

References

• Component Capabilities
• Component Test Overview
• Requirements Structure
• Security Criticality Analysis