🛠️Ways of Working
The Data & Insights Team has unique ways of working compared to the other engineering teams at Vetspire due to the scope, scale, and number of stakeholders involved, both internally and externally. The team's processes, priorities, and ownership are determined collaboratively by the engineering team and the various stakeholders.
Prioritization
The Data & Insights Team collaborates with various stakeholders in our daily operations, including different business functions (e.g., accounting, front-line support), our clients (Thrive and our commercial users), and the engineering team itself. Each stakeholder has their own requirements, priorities, and roadmap initiatives.
To address this, the Tech Lead of the Data & Insights Team, Chris Bailey (@vereis), takes responsibility for closely working with each stakeholder to prioritize and determine the team's tasks.
Once proposed, these priorities are reviewed and approved by the Tech Lead and Vetspire's CEO, Sam Ginn (@samginn), and are then discussed during Epic Grooming with the wider team.
It's important to note that priorities can change on an ad-hoc and ongoing basis. However, it remains the responsibility of the engineering team to understand and effectively respond to these changes.
Please refer to the Data & Insights Team's Approved Priorities for the most up-to-date list of the team's priorities, including any proposed changes.
Grooming
During our grooming calls, the Data & Insights Team aims to refine "asks" or more concrete bugs received from our stakeholders into actionable tickets that can be actively worked on by the team.
High-level "asks" are typically categorized into "Epic Track" projects or "Business-as-usual Track" (BAU Track) tickets, and the approach to working on them may differ slightly.
Similarly, bugs are usually grouped into Epic Track projects when a suitable medium-term fix is not applicable.
BAU Track Grooming
During our sprintly grooming call, any stakeholder can bring up a few "asks" or bugs for grooming. For "asks" in particular, it is recommended that stakeholders present the problem to be solved rather than coming with a preconceived solution. More details about this can be found in our good ticket guidelines.
Once discussed in the grooming call, the engineering team engages with stakeholders and other team members to gather additional details about the ask. Key aspects the team aims to understand include:
Core acceptance criteria (AC) for the ask
Importance and rationale behind the ask
Clients impacted by the ask
Wider impact on other clients
Point estimate for the ask
Additional considerations related to the ask
Reasons to defer or not proceed with the ask
If an "ask" is accepted as a standalone item, the engineering team creates tickets based on our good ticket guidelines as necessary to address the ask.
For bugs, we require them to be reproducible. If a bug cannot be reproduced, the engineering team may create an investigation ticket with a time limit to attempt bug reproduction.
Ideally, bug tickets should include the following information. The engineering team collaborates with the bug's stakeholders and other team members to establish:
Steps to reproduce the bug
Impact of the bug on users
Users affected by the bug
Has the bug ever worked? If not, it may be a feature request rather than a bug.
Once established, similar to "asks," the engineering team creates tickets following our good ticket guidelines as necessary.
The created tickets are then added to the team's groomed backlog
for consideration during Sprint Planning.
Epic Track Grooming
Grooming for Epic Track asks and requirements typically occurs separately from the team's regular sprintly grooming calls.
Details of the asks and requirements are documented by the Tech Lead and the stakeholder(s) of the epic on an ad hoc and ongoing basis before the epic development begins.
Once a specific epic track project is approved as a priority and added to the team's approved priorities, two meetings are scheduled:
Epic Grooming/Kickoff: This meeting involves relevant stakeholders and engineers to transform the high-level requirements of the epic into individual asks. These asks are then groomed with the team, similar to normal BAU Track asks. The high-level asks should include the required changes, features, acceptance criteria, definitions of done, and impact scoping. The team may create tickets following our good ticket guidelines.
Technical Kickoff: After capturing tickets representing the core asks of an epic, another meeting is scheduled primarily with engineers (though stakeholders may join if desired) to further break down the asks into small engineering task tickets. These task tickets can be actively worked on during our sprints. They should either link to or replace the high-level asks defined during the Epic Grooming/Kickoff meeting.
Sprint Planning
The Tech Lead collaborates with various stakeholders to incorporate BAU-track tickets into sprints on a rolling basis. Tickets may be deferred or delayed if other tickets align more closely with our priorities.
Additionally, the Tech Lead works with the engineering team and stakeholders to fit Epic Track projects into our sprints, as defined by our priorities.
These sprints and their contents are communicated directly to our stakeholders during our sprintly Roadmap Planning meeting.
Development
The Data & Insights Team always has two independent parallel tracks of work in progress: the Epic Track and the BAU Track workstreams.
While the team operates in sprints to align with the wider business in terms of deployment and planning, the team's work process is primarily epic-based.
Prior to starting any epic, two engineers are designated as Epic-Track engineers, while the remaining engineer(s) on the team are designated as BAU-Track engineer(s). The Tech Lead provides support to both tracks in addition to their core duties and requirements.
Epic Track Development
Epic-Track Engineers focus exclusively on tickets related to a specific epic for its entire duration unless otherwise approved by the Tech Lead. This approach allows Epic-Track Engineers to immerse themselves deeply in projects, minimizing distractions and context switching, which have historically posed challenges for the Data & Insights Team.
Ideally, collaboration between Epic-Track Engineers is seamless. They have the freedom to pair up or split up on issues and are expected to perform code reviews on each other's pull requests (PRs) to expedite delivery. Regular syncs with the Tech Lead are encouraged to address any blockers that arise.
This track of work follows the wider engineering team's ways of working, with additional considerations based on the Data & Insights Team's values and definition of done.
BAU Track Development
Business-as-usual Track Engineers handle multiple parallel streams of work that are priorities for the wider business at all times. These streams of work include:
Supporting Rotation: During one week per sprint, the Data & Insights Team is responsible for handling the Vetspire Support Rotation. The BAU Track Engineer takes charge of all support rotations falling under the D&I team's purview for the duration of an epic.
DataSync: The BAU Track Engineer attends weekly DataSync meetings and works on tickets from the DataSync
board whenever no other critical issues are being addressed.
BAU-Track Tickets: The BAU Track Engineer is responsible for working on non-epic track tickets scheduled for our sprints.
Resolving Sentry Issues when time permits: The Tech Lead allocates time in each sprint to address Sentry issues.
Miscellaneous Development: The BAU Track Engineer is free to pursue OKRs, personal learning and development, and contribute to open-source projects.
The BAU Track Engineer can prioritize their time, but they must give weight to Support Rotation, DataSync, BAU-Track Tickets, and Sentry Bugs (up to the allocated estimated point worth in any given sprint) in that order before deferring to miscellaneous development tasks.
The BAU Track Engineer can rely on the team's Tech Lead for additional support, task distribution, and other requirements.
Retrospective
Once every two sprints, the team will undergo a Retrospective meeting. The format of the meeting is to be determined prior to any meeting starting and is not fixed.
The person responsible for running the meeting will switch on a rotational basis every two sprints.
Last updated