Working with your team

The rituals, tickets and written habits that software teams use to plan and coordinate work.

Also called daily scrum, daily standup

What: A short daily meeting, often 15 minutes, where the team shares progress toward the current goal, the next step and anything blocking them.
Why: It surfaces blockers early and keeps the team coordinated. It is for the team, not a report to the manager.
Example: Yesterday: finished the export endpoint, PR is up. Today: address review comments and start the CSV tests. Blocked: need access to the staging bucket.

Watch out

Listing every small task you touched instead of progress, next step and blockers.

Also called user story, issue, Jira ticket, acceptance criteria, ticket

What: A ticket describes a piece of work; acceptance criteria are the checks that must be true for it to count as done.
Why: Clear criteria stop you building the wrong thing. If they are missing or vague, ask before starting, not after the review.

Watch out

Starting to code from the title alone and discovering in review that the expected behaviour was different.

Also called estimation, planning poker, story points

What: Relative sizes teams give to tickets, based on effort, complexity and uncertainty, rather than exact hours.
Why: They help a team plan how much fits in a cycle. For a junior, the honest range and the uncertainty matter more than the number.

Watch out

Giving an optimistic estimate to look fast, then quietly working late to meet it.

Also called sprint planning, sprint review, iteration, sprint

What: A fixed period, often one or two weeks, that starts with planning what to do and ends with reviewing what was done.
Why: Knowing the cycle tells you when to raise risks, when scope is agreed and when your work will be shown to others.

Also called retro

What: A regular team meeting to discuss what went well, what did not and what to change in how the team works.
Why: It is the safest place for a junior to suggest improvements, because the meeting exists for exactly that.

Watch out

Staying silent for months, or turning a retro point into blame of a person.

Also called async communication

What: Messages that make sense on their own: what, why, current state, link and what you need, without assuming the reader was in the room.
Why: Teammates in other time zones, meetings or weeks later can act on them without a follow-up question.
Example: Instead of "fixed it", write: "Fixed the duplicate emails bug (PR link). Cause was a retry without an idempotency key. Deployed to staging, will ship tomorrow after QA."

Also called PM, product manager, designer

What: Product managers decide what to build and why; designers decide how it looks and behaves; engineers decide how to build it and flag trade-offs.
Why: Early, specific questions to product and design prevent rework. They value engineers who explain cost and risk in plain words.

Watch out

Changing agreed behaviour on your own because it was easier to build, without telling anyone.

Also called English as a second language, ESL

What: Short sentences, common words, one idea per message and a structure people can scan, useful whether English is your first language or not.
Why: Most tech teams work in English across many first languages. Clear and simple beats fluent and long.

Watch out

Staying quiet in meetings because of your accent, when a short written follow-up would get your point across.

Go deeper