Versions Compared

Version Old Version 1 New Version Current
Changes made by

Jan Tenenberg

Jan Tenenberg

Saved on

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.

This page describes the rule of engagement by which Vertic’s team delivers its work, including project implementations and support. These rules must be followed consistently and are designed to bring efficiency and productivity to the process.

...

Rule Number

Engagement Rule

Detailed Description

Impacted Groups

1

Slack or email is not to be used for discussing requirements/specifications unless the outcomes are captured in an associated Jira ticket.

The purpose of this rule is to ensure all relevant details for any given ticket are captured within the ticket itself rather than in multiple channels.

All of Vertic and its contractors.

2

Detailed Ticket Content Creation

When creating tickets, the following information is mandatory:

  • Salesforce Org details to ensure the technical team knows in which environment to work

  • Quick Overview of the purpose of the ticket to ensure the technical team understands the context in which they are developing. This could include the greater solution and how this tickets fits into this.

  • Specific Instructions on what needs to be developed including the following:

    • Impacted Object References (API Names)

    • Impacted Field Names (API Names)

    • Detailed Field Mapping (API Names) where this is relevant

    • Screen Mockups (or marked up screenshots) if the user interface is to be changed

    • Evaluation Conditions, for example:

      • If <<field_name>> is greater than 120 then set <<field_name>> to Active

    • Execution Logic which could be documented as pseudo code or as a diagram

Vertic’s Consulting Team in Australia

3

Support/Defect Ticket Content Creation

Where a ticket is describing a defect, also add the following details:

  • Description of the error/defect

  • Loom video showing the error in action

  • URL to the record causing the error

Vertic’s Consulting Team in Australia

4

Feasible Ticket Structure

When a ticket spans across multiple functional requirements/specifications, create subtasks for each logical piece of development so it can be better managed by the technical team. This is particularly important when a ticket covers work across multiple days.

Vertic’s Consulting Team in Australia

5

Comments on Tickets

Once a ticket is being worked on, comments must be provided at the end of the working day to ensure the managing consultant has the required knowledge to update/manage the client.

Technical Team in Europe

6

Ticket Review

In order to improve ticket quality, the following process will be performed for each ticket:

  1. All tickets, once created, will be initial placed into a swim lane called Technical Review within the project board. This will be done by Monday of each week.

  2. The technical team will undertake a review of all tickets within this swim lane and feedback will be provided via comments on the ticket. This will be done by Wednesday of each week.

  3. Any feedback will be incorporated into the ticket and then it will be moved to Selected for Development. This will be done by Friday of each week.

  4. Only tickets from Selected for Development can be put into the planner for the technical team to be worked on.

All of Vertic and its contractors.

7

Clearly articulate Priorities

It is critical to clearly let the technical team know about priorities and expected timelines; this can be done via email with specific references to Jira tickets in the planner. Any issues with the documented timelines must be communicated by the technical team to the consulting team.

All of Vertic and its contractors.

8

Fortnightly Plan

The planner should be structured across a fortnight rather than a single week; this will allow for better planning and for managing workload much better.

All of Vertic and its contractors.