Skip to end of metadata
Go to start of metadata

You are viewing an old version of this page. View the current version.

Compare with Current View Page History

« Previous Version 5 Next »

Goal

Our goal for moving triaging to a separate project and process is to minimize triage time as well as allow the team to have more dedicated engineering time. 

Our goal is to limit triaging to no more than 30-60 minutes per issue in order to resolve more issues in our backlog across all CAT levels.


What is the process?

  1. A ticket is created by an internal Customer using the Employee Support Portal

  2. Monitor Customer Request Queues

    1. Mavericks

      1. Content & Authoring

      2. Catalog & Publishing

      3. Platform & Infrastructure

    2. Spartans

      1. Commerce & Payment

      2. Learner Experience

      3. Business & Enterprise

  3. Set appropriate fields for each issue

    1. Assign to yourself

    2. Reach

      1. How many people are affected?

    3. Impact

      1. What is the impact of this issue, for example: completely blocked, workaround available, working but ugly

    4. Priority (based on reach/impact)

    5. Team (may not be the team you are on)

    6. Platform Area

    7. Ensure Description includes: 

      1. Steps to reproduce

      2. Necessary links and screenshots

      3. Explicit expectation of behavior

      4. Any timeline or urgency to take note of

  4. Move CR ticket to Triaged Jira status

  5. From this point on:

    1. Move to PROD Development Workflow

    2. CR ticket should update automatically based on the development ticket's progress

FAQ

What if the ticket does not provide enough data to complete the above fields?

  • Add a comment asking the customer/reporter to provide additional context or missing information and move to Waiting for Customer status

    • It will move out of the triage queue at this point, move it back to In Triage once the reporter has responded 

What if the Product Component (second drop down) is not a part of the list?

  • Ensure that the Platform Area is still set (first drop down)

  • Add an internal comment on the CR ticket and tag Seth and I - we can work to get it added appropriately

What if I quickly know that it's a configuration change that does not need any code changes?

  • Add a label "configuration" to the CR ticket

  • Resolve work within CR ticket itself

What if this issue relates to active development work?

What does moving something to Triaged do?

  • This will create a corresponding Prod development ticket and move it into Backlog or Prioritized by default based on the CAT/Priority

When does the CR ticket close?

  • This ticket will automatically resolve once your development ticket is moved to Closed

  • Once you complete a development task, you should feel empowered to validate that the issue has been resolved and close once you've validated

    • If the customer needs to reopen the ticket they can

    • If you do not have a way to validate yourself and must have the customer validate, you should ask them to do so on the CR ticket and not the development ticket



  • No labels