Create Feature

(Activity) for Tier: Release

View Training

PURPOSE

The purpose of this activity is to develop a feature that describes specific functionality to satisfy stakeholder needs. A feature is developed in collaboration with stakeholders and the team. Features are reviewed to ensure they are understood, achievable, appropriate, and deployable.

ENTRY CRITERIA

  • The team’s quality criteria for completeness and correctness of a new or modified Epic has been met.

WHEN

Feature development occurs continuously throughout the life of the project and may be triggered by creation of, or changes to an Epic.

SUB-ACTIVITIES

  1. Elicit Stakeholder Needs

    • Elicit stakeholder needs, expectations, constraints, and interfaces to ensure a mutual understanding of the requirements. This elicitation can be considered a detailed elaboration of work already defined in the contract.
    • Examples include but aren’t limited to: Collecting feedback in product reviews/demonstrations, interviews, user experience studies, brainstorming, and technology demonstrations.
    • Artifacts containing stakeholders needs should be linked to Features to provide background information for those defining and implementing the Feature.

  2. Analyze Stakeholder Needs

    • Analyze stakeholder needs to determine the next steps. This may include but is not limited to:

      • Drafting or updating a Feature (below),

      • Obtaining an understanding of the current and planned architecture capabilities to plan extentions to the architecture as early as possible or to rule out anything that clearly lacks return on investment.

        Note

        Example: A request for a desktop component in a web-only architecture or integration with an unknown, unapproved data source.

      • Researching the impacts to the user experience

      • Writing new user stories.

  3. Draft Feature

    • Create a Feature work item with a brief title and description in order to decompose higher level requirements into a feature that accomplishes a cohesive user-goal.
    • Link the Feature to its parent Epic work item.
    • Attach the source of stakeholder needs to the Feature work item.
    • Link interface specifications to Features that include significant or external interfaces and adorn the work item with an “Interface” tag. These requirements demand additional coordination cost.
    • Update the Feature’s Area Path and assign it to the appropriate functional component of the application. For example, an application may be composed of four major functional areas: Setup, Flight Scheduler, Flight Logger, and Reports. The feature would be assigned one of the four.
    • Determine the functional areas of the application with appropriate stakeholders if this has not been completed. Teams should leverage their user interface design and solution architecture to help determine functional areas (I.e. product modules).

    Note

    User stories that are subsequently created as children for a given feature will inherit the area path assigned.

  4. Elaborate the Feature

    • Describe the User-Goal of the feature within the description field. Ensure the intent of the feature is captured and any necessary actions or business process flow required to achieve the User-Goal. Simple language, a list of steps, or static description(s) are acceptable.
    • Continue to elaborate the feature until the desired scope is defined. Ensure it can be implemented, verified, and validated. Remove conflicting language, ensure it flows logically and adheres to team norms. Record continuous analysis and discussions within the discussion field of the work item.
    • Collect and respond to stakeholder feedback by continuously refining the Feature and communicating changes. Document feedback within the Discussion field of the work item.

  5. Determine Expected Usage

    • Determine expected usage by leveraging telemetry, subject matter expertise and customer input in order to assess current and future relevancy. Consider the following:

      • Number of users (unique or otherwise).
      • Expected frequency of use.

  6. Define Acceptance Criteria

    • Analyze and derive the most critical aspects of the Feature in order for it to be deemed an acceptable solution. Consider the parts of the Feature that:

      • Satisfy contractual obligations
      • Meet expectations from stakeholders (users, customers, the team, etc.).
      • Are fundamental aspects of the design (user experience or program).
      • Provide points of clarification that affect the scope.

    • Gather feedback from stakeholders, then document the final list as Acceptance Criteria

    Note

    It may be useful to align user stories with the acceptance criteria and/or the body of the Feature.

  7. Prioritize Features

    • Prioritize features in at least one of the following ways:

      • Assign a priority for each feature in the backlog per team procedures.
      • Stack rank features per team procedures.

  8. Review Feature with Stakeholders

    • Review the feature with stakeholders to obtain buy-in. These stakeholders include the feature team (people doing the work), users, customers, architects, and user experience architects/designers.

    • Mark the Feature as “Refined” once the following criteria are met:

      • Shared Understanding: Stakeholders have a shared understanding of how the application will change and why it is needed.
      • Achievable: Can be implemented, verified, and validated. Pay particular attention to the acceptance criteria.
      • Appropriate: Is it the proper solution for the end-user and customer.
      • Deployable: Can it be deployed into the target environment(s). This is often implicit in verification because the verification (pre-production) environment(s) mimics the production environment.

    Note

    Marking as “Refined” is commonly done via a board column on the Feature board.

EXIT CRITERIA

  • Feature requirement has been refined.

NEXT ACTIVITY

Write User Stories

Process Guidance Version: 10.4