This is an internal documentation. There is a good chance you’re looking for something else. See Disclaimer.

Team Guidelines

This page documents workflows, standards, and expectations that apply in day-to-day work but are often only passed on verbally.

Jira Tickets

Before creating a ticket, make sure no duplicate already exists.

  • Epic: every ticket must be linked to an epic. Use a generic epic such as NA: 2026 or Technical Improvement if no specific one applies.

  • Version: if the target version is not yet known, set latest (maps to master). The correct version is set when the work is picked up.

  • Labels: set the labels that apply to the ticket. We use DEV-Backend, DEV-Frontend, Rückwirkende-Änderung and Styling/UX.

  • Components: we do not use components; leave this field empty.

Where useful, attach a screenshot or a short video to the ticket. Do not use dark mode in screenshots or videos.

When moving a ticket to testing or closing it, check whether a follow-up ticket is needed for the next steps. If so, create one. Otherwise, the remaining work will be forgotten.

Scrum Meetings

  • The daily takes place every day at 10:00. From Tuesday to Thursday the team is normally in the office; on the other days the daily is held via Microsoft Teams. Each sprint has a designated sprint lead who facilitates the daily.

  • After the daily the team normally plays three rounds of Curve.

  • Refinement takes place every Wednesday, normally at 13:00. All tickets are estimated in story points using Fibonacci numbers (1, 2, 3, 5, 8, etc.). When the meeting is held in the office we use physical cards; when held remotely we use Scrum Poker Online.

  • Review and retrospective take place every second Wednesday at 10:00. On those days the daily is moved to 9:30.

    In the review, each developer briefly presents the relevant work from the sprint. Tickets that are not relevant do not have to be shown or mentioned.

    The retrospective is prepared by the sprint lead and usually has two parts: a check-in or energizer (for example Gartic Phone), followed by the actual retrospective. Suitable formats can be found on funretrospectives.com. Selected points from the retrospective are followed up on (most are not pursued further); for those we create a ticket or schedule a dedicated meeting.

  • Sprint planning takes place on the Thursday of the review week at 10:00. It is split into two parts:

    • Planning 1: together with the CTO, the product owner and the business analyst we decide which tickets to plan for the next sprint.

    • Planning 2: we break the planned tickets down into subtasks; often a ticket gets exactly one subtask. As a rough conversion: 1 SP = 2h, 2 SP = 4h, 3 SP = 1d, 5 SP = 2d, 8 SP = 3d.

  • The business review takes place individually between each developer and the product owner / business analyst.

The resource planning for the sprint and the sprint review slides are kept in the Technik SharePoint folder. In the resource planning, each developer enters their attendance for the upcoming sprint. In addition, each developer has an individual productivity factor that is applied to their available time. The factor depends on how much work outside of the sprint a developer typically handles and on their personal working speed.

Tools

  • Bitwarden password manager

  • Claude AI assistant

  • GitLab source control and merge requests

  • IntelliJ IDEA backend development

  • Jira issue tracking and project management

  • Microsoft Office Word, Excel, Outlook, Teams, Planner, etc.

  • OpenShift platform where installations run; includes Grafana for log access

  • Slack team communication

  • SonarQube / SonarLint code quality analysis

  • TeamCity deployment

  • VS Code all other repositories

  • WireGuard VPN for remote access

  • YourKit Java profiler for out-of-memory analysis

Team Rules & Expectations

AI Usage

Tocco provides Claude as an AI tool. AI tools are an aid, not a replacement for your own judgement. The following rules apply when using any AI tool:

  • AI-generated code must always be reviewed before merging.

  • Never create a merge request with AI-generated code without fully understanding it.

  • Always validate critical logic manually.

  • Never enter customer data into external AI tools.

Support Handling

3rd level support tickets are assigned to a team member by the CTO. By the time a ticket reaches us, a 2nd level analysis should already have been carried out.

When receiving a support ticket, first check whether it is time-critical. If so, address it immediately. Otherwise, you can finish your current work first.

When picking up a ticket:

  • Read through all existing comments thoroughly.

  • Check that the ticket contains a description of how to reproduce the problem. If essential information is missing, request it before proceeding.

  • Analyse the behaviour and implement a fix if required.

While working on the ticket:

  • Create a corresponding TOCDEV ticket for bug fixes so that it is visible which version the fix was applied to.

  • If a ticket takes longer than expected, add an interim status update as a comment.

  • When handing the ticket back, document what was done and what (if anything) remains open.

  • If any information in your comments is intended for internal use only, mark it as such. Otherwise, your explanation may be forwarded to the customer.

  • If you are stuck, ask the team for help.

Reworks

Reworks should be handled in between regular work where possible. If you do not have the time or the rework is too complex to do quickly, you are responsible for ensuring it gets scheduled in the next sprint or discussed again.

Absences

Absences (illness, deviations from regular office times, etc.) are posted in the #technik_intern channel and added as a calendar entry in Outlook. Home office days are also added as a calendar entry in Outlook.

If you are sick, submit an absence report via the intranet.

Questions

Questions are asked in the #backend-frontend channel so that everyone can benefit from the exchange. Use threads to keep discussions together. This way everyone can follow along and it is visible who helped, when, and with what.

Code Reviews

Code reviews follow the rules and conventions defined in the Contributing Guidelines.

The goal is to get merge requests merged as quickly as possible. This applies to both sides:

  • As an author keep your changes focused and easy to review; respond to feedback promptly. Make sure the use cases actually work. Do not rely solely on unit tests passing. Avoid keeping too many tickets open at the same time; finish what you have started before assigning new ones.

  • As a reviewer review open merge requests in a timely manner so authors are not blocked.

Recurring Tasks

Some work is not tied to sprint tickets and is picked up in between regular work:

  • Bug queue: collects bug tickets that are not assigned to a specific sprint. The queue is usually worked off towards the end of the sprint when there is remaining capacity. Urgent issues are picked up immediately.

  • #ci channel: broken auto merges and failing Cypress tests are reported in the #ci Slack channel and need to be fixed promptly.