Jira Ticket Submission

The MKTGWEB JIRA project was created in 2015 and no longer supports the processes, workflows and technology of the Web Strategy & Operations Team. Because of this, the Web Strategy & Operations Team is moving to a new Jira project – MKTGWEBOPS starting July 5, 2022. The new project encompasses updated workflows and updated fields that are required in order to successfully complete a ticket.

The purpose of this new project is to help increase efficiencies, enabling the team to work faster and smarter. Additionally, it will allow us to conduct thorough reporting on team metrics that are not possible with the MKTGWEB project. This includes data broken down by program, type of request, overall complexity, team capacity, etc.

The MKTGWEBOPS project was copied from the MKTGWEB Jira project, so certain fields and workflow statuses are exactly the same. However, there are workflow changes and additions of new fields to note (see below).

Quick Links:

Jira Ticket Workflow Process

New: All MKTGWEBOPS tickets start in the New status. At this point, once the ticket is ready for Web Production to start working on it, assign the ticket to the Web Production Manager.

Additional Info Required: This status is used when additional information is required in order for Web Production to start the ticket. This could mean we need more information, additional assets, etc.

In Progress: Once a Web Producer starts working on a ticket, they will assign the ticket to themselves and change the status to In Progress.

Under Review (Staged): Once a Web Producer has finished completing the request in the ticket, they change the status to Under Review (Staged) and tag the Reporter through a comment that the work is ready to be reviewed. Staging the page means that the reviewer is looking at a staged (not live) page for review.

Ready to Go Live: This status should be used when an update is in Under Review (Staged) and is approved and ready to push live to the site. The ticket will then go to Under Review (On Production) so that the update can be checked on the live site as well.

Under Review (On Production): Once a Web Producer has finished completing the request in the ticket, they change the status to Under Review (On Production) and tag the Reporter through a comment that the work is ready to be reviewed. On Production means the update was pushed live to the site and review will happen on the live site.

Changes Required: Once the Reporter has had a chance to review the changes, they can provide any callouts/changes/feedback in a comment and change the status to Changes Required.

Closed: Once a ticket has been reviewed and the request is implemented on the page, the Reporter sets the status to Closed. 

The updated workflow indicates which team is responsible for doing the work in each status. The major changes from our MKTGWEB workflow that we will be using in the MKTGWEBOPS workflow are:

  • Once a ticket is closed, you are no longer able to reopen it. This will help us avoid asking for additional requests once the initial ask of the ticket is complete.
  • The differentiation between whether something is Under Review Staged or On Production will hopefully help guide the process along of staging content vs pushing it live.
  • The assignee of the ticket should remain with Web Production the entire lifecycle of the ticket. If that for some reason isn’t followed, the ticket needs to be assigned to the Web Producer by the time the ticket is closed. 
  • If partners outside of Web Production need visibility on the ticket, they can assign themselves the ticket in the Additional Assignee field and set up their filters accordingly to filter for tickets where they’re the Assignee or Additional Assignee on the ticket.
  • Additional Info Required is a new status that can be accessed through every other status within the workflow. This new status is meant to be used whenever the ticket needs additional information, such as more of an explanation or additional assets. This will help both Web Producers and Brand MM/ODG know when a ticket requires additional information and isn’t just sitting in the “New” status causing confusion.

Jira Ticket Fields

(*) Indicates a required field.

FieldOptions & Explanations
Project*
MKTGWEBOPS
Issue Type*
Epic
Used as a “parent ticket” to host subtickets. Epic’s are usually used for larger projects that need to be broken down into smaller tickets. 

Launch
This is a Work In Progress (WIP) and will be complete with a future phase of the Jira project. Will be used for new program launch tickets

Other
This ticket type is for a request that doesn’t fall within any of the other categories.

Project
This ticket type is used for Internal Web Ops Team Projects. An example would be tickets to update pages within our TAP 2.0 site that we create internally for the team.

Multi-Program
This is a WIP and will be complete with a future phase of the Jira project. The proposed use of this ticket type will be to select multiple programs and Jira will automatically create sub tickets for each program selected.

Taxi
This ticket type is used for any requests to update our Taxi Lead Forms.

Minisite
Used for requests to update a page on our Minisites.

Paid
This ticket type is used for any requests to update anything on our Paid Sites.

Organic
This ticket type is used for any requests to update anything on our Organic Sites.

edX
This ticket type is used for any requests to update anything on our edX Sites.
Summary*
Title of the Ticket
Assignee
Similar to the MKTGWEB project, this is the assignee of the ticket. 
Additional Assignee
This is a new field to the MKTGWEBOPS Jira Project. The Additional Assignee field is used to assign the ticket to more than one person. Any reviewer of the ticket can add themselves as an Additional Assignee so that the ticket shows up in their queue. Web Producers should also add themselves as Additional Assignees if they want to track the ticket while it goes through reviews.
Reporter*
Automatically assigned to the person who opened the ticket. This can be changed manually.
Program*
Similar to the MKTGWEB project, this is the Program for which you are proposing the change be made.
Labels
Similar to the MKTGWEB project, you can add labels to the ticket. Note: this is case-sensitive.
Request Type*
This is a new field that helps specify the type of request you are making in the ticket. These are broken out by Organic, Paid, Minsite, Taxi, Launch, Other, Multi-Program and Projects.
Please reference either the Organic/Minisite, Paid/Taxi, or edX Ticket Submission Section of our TAP site for a breakdown on what each type of request is, and what the equivalent Story Point for that request is. 
Attachment
Similar to the MKTGWEB project, you can attach any docs/files/comps/etc. to this section.
Priority*
Similar to the MKTGWEB project, this field is for the priority of the ticket. For a breakdown of priorities, please reference the Ticket Priority section of the Ticket Submission Page.
Due Date*
This is the date when the ticket ideally should be in the “Under Review” status.
Live Date*
Extra field used to indicate when the ticket should/can go live. This is not a required field.
Sprint
Used to organize the ticket into a designated Sprint cycle. Please reference the Weekly Sprint Process of the Ticket Submission Page for more information on our Sprint process. 
Story Points
A measurement of size/complexity of a ticket. Please reference either the Organic/Minisite, Paid/Taxi, or edX Ticket Submission Section of our TAP site for a breakdown on what each type of request is, and what the equivalent Story Point for that request is. 
Original Estimate
Will potentially be used in the future for time tracking purposes.
Remaining Estimate
Will potentially be used in the future for time tracking purposes.
Linked Issues
Used to link tickets together.
Issues
Input the ticket you wish to link.
Specific Site*
This field only shows if you select “Minsite” as an issue type. This field is used to indicate which Minisite is proposed to be updated.
Page Type*
This field only shows if you select “edX – Contentful” as an issue type. This field is used to indicate what type of page on edX’s site is proposed to be updated.

Weekly Sprint Process

Web Production tickets are organized into weekly sprints, starting Monday and ending Friday. All tickets are assigned to the Web Production Manager. Then, Brand Marketing Management and ODG managers prioritize and organize each ticket within the Web Strat & Ops Jira Sprint Board. 

On Monday, when the sprint begins, Web Producers pull tickets into their own queue from the top of the sprint board. As tickets are completed, placed into under review, or are waiting on more information, the Producers then pull an additional ticket, one by one, from the top of the board into their queue. Producers repeat this process until all tickets within the Sprint have been assigned and completed. If a ticket requires additional information, the due date and sprint should be updated accordingly once the information is added.

If all tickets have been assigned prior to the end of the sprint, Producers can assign themselves tickets from the following week’s sprint and move it into the current weeks’ sprint to accurately reflect when the ticket is being worked on. When all tickets within a sprint are reviewed and closed, the sprint will be marked as complete. We aim to have a Sprint open, at most, for 2 weeks total. 1 week would be the actual sprint week, and 1 extra week for any reviews (including copy live reviews) to happen. It is the Reporter’s responsibility to close the ticket out in a timely manner once the work is approved. If the ticket is not closed by the Reporter within 3 business days, Web Production will comment and tag the reporter to check in. If no response is received, Web Production will reach out by chat. If a ticket requires any further edits after it has been closed, we will require a new ticket to be opened.

When should I submit a ticket to get it placed into a sprint?

In order to finalize the work that is included in each sprint, there are Sprint Cut-Off days. This is the last day tickets can be added to the upcoming sprint. All tickets must be added to the sprint by the end of day the Thursday prior to the start of the sprint. Any tickets added for the next sprint, with the exception of Urgent ones, will be asked to be moved into a future sprint.

MondayTuesdayWednesdayThursdayFriday
X
X
X
Sprint #1 Cut-Off
X
Start of Sprint #1
X
X
Sprint #2 Cut-Off
End of Sprint #1
Start of Sprint #2
X
X
Sprint #3 Cut-Off
End of Sprint #2
Start of Sprint #3
X
X
Sprint #4 Cut-Off
End of Sprint #3

Please remember that sprints are determined by more factors than ticket submitted date. If complexity points have maxed out, it is possible your ticket will be added to a future sprint.

Ticket Priority

Use the below as a guideline to set your ticket priority.

Urgent

  • This project is extremely time-sensitive and needs attention from a web producer within 24 hours in order to fulfill university requests. Web production will communicate if there are any concerns with timing. 
  • This project is reserved for quick edits on the site that are detrimental to the brand/school.
  • The turnaround time for such requests is within 1 business day. For such requests, please also flag the request with the web production manager.

High

  • This project is time-sensitive and has a hard deadline, which cannot be adjusted.
  • This project uses standard Organic/Minisite, Paid/Taxi, or edX Turnaround Times based off the story point and type of request.
  • This project fulfills a priority request from the school.

Medium

  • This project uses standard Organic/Minisite, Paid/Taxi, or edX Turnaround Times based off the story point and type of request. Deadline is flexible pending the web producer’s bandwidth on other high priority projects. 
  • This project will positively impact site performance and is created to reach marketing goals.
  • This project was requested by an internal team or is a lower-priority request from the school.

Low/None

  • This project uses standard Organic/Minisite, Paid/Taxi, or edX Turnaround Times based off the story point and type of request, but does not have a hard deadline. 
  • This project is for longer-term projects, general site audits, and explorations that are going to be tested to enhance marketing goals.

Organic/Minisite Ticket Turnaround Times & Story Points

  • Issue TypeStory PointsService Desk SLA (# of Business Days)
    Copy/Image Edits (1-4 pages)
    Edits to existing pages – updating language or changing dates.
    1
    5-7
    Copy/Image Edits (5-9 pages)
    2
    5-7
    Copy/Image Edits (10-39 pages)
    3
    8-10
    Copy/Image Edits (40+ Pages)
    4
    10-12
  • Issue TypeStory PointsService Desk SLA (# of Business Days)
    Design Layout Changes (1 – 9 pages)
    Changes the include design elements or blocks to be added/removed from pages.
    3
    8-10
    Design Layout Changes (10+ pages)
    4
    10-12
  • Issue TypeStory PointsService Desk SLA (# of Business Days)
    New Basic Sidebar Page
    A simple interior page with few or no design elements and a sidebar nav.
    Live basic sidebar layout
    2
    5-7
    New Complex Sidebar Page
    An interior page with somewhat complex design elements or imagery.
    Live complex sidebar page
    3
    8-10
    New Full-Width Page
    Fluid Width page with somewhat complex design elements or imagery.
    Live complex sidebar page
    3
    8-10
    New Complex Fluid-Width Page
    A homepage or OLP with many design elements and organizational widgets.
    Live complex fluid-width page
    4
    10-12
  • Issue TypeStory PointsService Desk SLA (# of Business Days)
    Faculty/Student Profiles – Links to External University Site
    Updating faculty information or adding new faculty members that link to the school’s external site.
    2
    5-7
    Faculty/Student Profiles – Links to Internal Program Site
    Updating faculty information or adding new faculty members pages to the site.
    3
    8-10
  • Issue TypeStory PointsService Desk SLA (# of Business Days)
    Template Page Rollout – Finalized
    Duplicating/Following a template to roll out a change across our program sites.
    2
    5-7
    Template Page Rollout – Testing Phase
    Creating/Testing a template to roll out a change across our program sites.
    4
    10-12
  • Issue TypeStory PointsService Desk SLA (# of Business Days)
    Set Up Test (2 versions)
    Adding versions to a design elements or blocks on pages.
    4
    15
    Set Up Test (3+ versions)
    4
    20

  • Issue TypeStory PointsService Desk SLA (# of Business Days)
    Copy/Image Edits (1-4 pages)
    Edits to existing paid landing pages – updating language or changing dates.
    1
    5-7
    Copy/Image Edits (5-9 pages)
    2
    5-7
    Copy/Image Edits (10-39 pages)
    3
    8-10
    Copy/Image Edits (40+ Pages)
    4
    10-12
  • Issue TypeStory PointsService Desk SLA (# of Business Days)
    Design Layout Changes (1 – 9 pages)
    Changes added/removed from design elements or blocks on paid landing pages.
    3
    8-10
    Design Layout Changes (10+ pages)
    4
    10-12
  • Issue TypeStory PointsService Desk SLA (# of Business Days)
    Clone/Edit to Existing Taxi Form
    Changes made on a single taxi form.
    2
    5-7
    Clone/Edit to Multiple Taxi Form
    Changes made on a multiple taxi forms.
    3
    8-10
    Create New Taxi Form
    3
    8-10
  • Issue TypeStory PointsService Desk SLA (# of Business Days)
    Clone & Update Existing PLP
    Duplicating another paid landing page and adapting it with small edits.
    2
    5-7
    New PLP Creation 1+ Pages Similar Design
    New paid landing page builds with a similar template on 1+ pages.
    3
    8-10
    New PLP Creation 1+ Pages Varying Design
    New paid landing page builds with a differing designs on 1+ pages.
    4
    10-12
  • Issue TypeStory PointsService Desk SLA (# of Business Days)
    Template Page Rollout – Finalized
    Duplicating/Following a template to roll out a change across our sites
    2
    5-7
    Template Page Rollout – Testing Phase
    Creating/Testing a template to roll out a change across our sites
    4
    10-12
  • Issue TypeStory PointsService Desk SLA (# of Business Days)
    Set Up Test (2 versions)
    Adding versions to a design elements or blocks on paid landing pages.
    4
    15
    Set Up Test (3+ versions)
    4
    20

edX Ticket Turnaround Times & Story Points

  • Issue TypeStory Points
    Copy/Image Edits to 1 Page
    2
    Copy/Image Edits to 2+ Pages
    3+
  • Issue TypeStory Points
    Design Layout Changes
    3
  • Issue TypeStory Points
    New Boot Camp/Micro Boot Camp About Page
    Live MicroBootCamp page
    Live Boot Camp page
    4
    New Degree About Page
    Live degree about page
    4
    New FLEX About Page
    Live FLEX About Page
    4
    New Product Landing Page
    Live product landing page
    4
  • Issue TypeStory Points
    New UUID/URL
    Web Production only handles Boot Camp UUIDs and URLs, please reach out to Ned Elwell for all other lines of business.
    2
    Publish UUID/URL
    Web Production only handles Boot Camp UUIDs and URLs, please reach out to Ned Elwell for all other lines of business.
    2

If you have a request that doesn’t fit within the above categories, please reach out to the Web Production Manager.