Skip to content
BoKSA

Collaboration & Agile Fundamentals

Collaboration & Agile Fundamentals

Use this page to revise the vocabulary of working with Git and in a Scrum team.

Git concepts

A repository holds a project's full history; the working directory is your current checkout of it; the staging area is where you assemble a commit before making it; a commit is a saved snapshot; a branch is an independent line of development; a remote (usually called origin) is a copy of the repository hosted elsewhere (e.g. GitHub, GitLab).

Basic commands and workflow

init/clone start a repository locally; add stages changes; commit saves them; log/diff inspect history; branch/checkout/switch manage branches; merge combines them; pull/push/fetch synchronise with a remote.

Feature branches, conflicts, and hygiene

A feature-branch workflow means creating a branch per change, committing to it, pushing it, and opening a pull/merge request rather than committing straight to main. A merge conflict happens when two branches change the same lines differently — Git can't guess which version you want, so you resolve it by hand. Good practice: meaningful commit messages, small commits, and a .gitignore so generated files and secrets never enter the repository.

Scrum roles, events, and values

  • Roles: the Product Owner owns the backlog and priorities; the Scrum Master protects the process and removes blockers; the Developer builds the increment.
  • Events: Sprint Planning (deciding what to build this sprint), the Daily Scrum (a short daily sync), the Sprint Review (showing the increment to stakeholders), and the Sprint Retrospective (the team reflecting on how it worked together).
  • Values: Courage, Focus, Commitment, Respect, Openness.

Scrum artefacts and planning tools

  • The Product Backlog is the full, prioritised list of everything that might be built; the Sprint Backlog is what the team committed to for this sprint; the Increment is the working product resulting from a sprint.
  • An Epic is a large body of work broken down into smaller user stories; a user story typically includes a description, tasks, acceptance criteria, and a Definition of Done (DoD).
  • A Burndown chart shows remaining work over time (ideally trending to zero); a Burnup chart shows completed work climbing toward the total scope. MoSCoW prioritises work into Must have, Should have, Could have, Won't have.

Code review and written collaboration

A code review checks a change for correctness, readability, and maintainability, before it's merged — from both the author's side (writing a reviewable change) and the reviewer's side (giving specific, constructive feedback). Clear written communication (a PR description explaining what/why/how, an issue comment that stands on its own) lets a team stay in sync without needing a meeting for every decision, and taking ownership of your deliverables means the Definition of Done is met before you call something finished, not after someone else notices it wasn't.

Starting Points

Key Points

  • You can explain the core Git concepts: repository, working directory, staging area, commit, branch, remote.
  • You can describe a feature-branch workflow from branch creation to merge request.
  • You can explain why merge conflicts happen and how you'd resolve one.
  • You can name the three Scrum roles and their main responsibility.
  • You can list all Scrum events and their purpose, and name the five Scrum values.
  • You can identify the Product Backlog, Sprint Backlog, and Increment, and explain the difference between an epic and a user story.
  • You can read a burndown/burnup chart and explain MoSCoW prioritisation.
  • You can explain what a code reviewer looks for, and what "taking ownership" of a deliverable means.