• All Feature Request tickets start here. This is a prioritized backlog of feature requests.
• Feature Requests can range from loosely defined to more defined
• Higher prioritized items should have more defined requirements/descriptions

• Feature Requests can exist without being tied to an Epic.
• An epic is created if a feature is too large to live as an individual feature request.
• Labels link together related Epics and Feature Requests

It's possible to tag or label on a feature request that isn't prioritized yet and filter on the Kanban board to not display those.

eStep 2 - "Framing" (Previously "Analysis" in current DCWW/ABC Brand board)

(Assess Business Value, Assess Research, Assess Design Exploration)

Feature Request moves this Step 2 - Framing when:

• Feature Request ticket is ready to be picked up for further business value assessment, research, or design exploration.
  • Feature Request ticket should be defined enough to be able to be picked up by design to explore. Sometimes, a title and brief description can suffice.
  • Design can be tapped to start explorations through an informal chat or kick-off by the Feature's Lead Product Manager. Or, Design can pick up a feature request to explore if they have extra time from ongoing major features. 
  • Example: GAM needs a lot more resources at the moment, so Design has extra time to tackle the next-highest prioritized Funnel Feature Request that needs designs.

While in Step 2 - Framing:

• Assessing Business Value
  • Product team determines Feature Product Lead, who then fleshes out Feature Request ticket more with requirements. Collaborative with Design if design is required–Design contacts determined.
• Assessing Research
  • Product and Design evaluate and/or conduct research as needed.
• Assessing Design Exploration
  
  • Designers will have their own internal design team review flow and feedback. 
  • Designers will also collaborate and review with Feature Product Manager throughout exploration. 
  • When designs are ready and have been reviewed with Feature Product Manager, early spec reviews for engineering feedback can also happen.
  • Once Designs are reviewed and approved by Feature Product Manager, Feature Request ticket moves to step 3.
    • After explorations are reviewed, Feature Product Manager should continue to assess: 
      • Does the business case make sense? Does Product want to move forward with this feature now knowing more of the research, designs, and constraints? 

Step 3 - Analysis

(Share-out Designs, Scoping, Legal, LOE) 

This column is "new" but really is a more broken out column of the existing "Analysis" columns on DCWW/ABC Brand board.

Moves into this Step 3 - Analysis when:

• • Design has finished bulk of feature ticket's exploration.
  • Designs have been reviewed and approved for larger share-outs by Feature Product Manager. 
  • Feature Request is ready to be reviewed more formally with the broader Product team as well as Legal or any other impacted teams (i.e. CP / EIA engineering teams). 

While in Step 3 - Analysis:

• Features and/or Designs are reviewed more formally with the broader Product team as well as Legal or any other impacted teams (i.e. CP / EIA engineering teams). 
• Based on broader team feedback and scoping:
  • Iterations on design and requirements happen based on feedback.
  • Product team continues to evaluate if the business case makes sense.
  • Feature Product Manager completes requirements documentation

Step 4 - Platform Ticket Creation

(Requirements Ready, Platform Tickets To Be Created)

Moves into this Step 4 when:

• Feature Product Manager has completed requirements documentation and is ready to create platform-level tickets.
• Appropriate share-outs and sign-off have happened by impacted teams.

While in Step 4

• Based on share-out discoveries, any larger stories can be broken down at this point to smaller stories on platform level boards. 
• Feature Product Manager and Platform Product Manager(s) create or clone to platform-level tickets.
• Feature Requests are qualified as "dev ready"

Step 5 - Execution

(Work is started on Platform Tickets)

Moves into this Step 5 - Execution when:

• Feature Product Manager and Platform Product Manager(s) have finished cloning or creating to platform-level tickets.
  • Stories on Platform Tickets begin at status "Dev Ready" and are ready for Platform team grooming.

While in Step 5 - Execution:

• Engineering teams have platform tickets. They can groom tickets and start work. 
• Stories under platform epics are now marked “Dev Ready" and moves along the engineering execution workflow. 

Step 6 - Resolved (Not Shipped/Enabled)