Guia PES

Method

How to work as a team without stepping on each other

Your way of working is defined at the end of the inception and revised at every retrospective. What you do counts as much as how you do it: 40 % of the project's ambition is methodological.

Roles: everyone owns something

The teachers are the product owner. Besides development, each team member makes sure one specific part is done well and delivered on time and in the right format.

Member 1

Inception

Both inception phases (in teams of 8, split between two people).

Members 2, 3 and 4

One sprint each

Sprint master of their sprint: planning, report, burndown and everything on the Drive on time.

Member 5

Services

Manages the service you offer to another team and the one you consume.

Member 6

Final demo

Prepares the demo: dataset, script and rehearsal.

Member 7

Closing

Coordinates the final documents: managerial report and release information.

Communication

With the teachers

Subject prefixed with [PES] n-grup nom-projecte and a description. Any team problem: the sooner, the better.

The project record track (PRT)

A shared spreadsheet that logs all the team's activity: classes, meetings, training, development, documentation. It overlaps with Git and Taiga, but it helps manage the team and is used to assess it.

  • Columns: date, duration, member, activity, story number and comments.
  • One person per row: a three-person meeting is three rows.
  • A separate sheet with the summary and statistics per member and iteration.
  • Updated from day one, and checked by the sprint master.
  • Consistent descriptions: always the same activity names.
ActivityWhat it covers
Reunió d'equipA meeting of (almost) the whole team, including meetings with the teacher.
Reunió focalA small subgroup working on a specific topic.
Classe passivaLecture hours.
FormacióLearning a new technology to use in the project.
DesenvolupamentCoding, testing, quality control, deployment.
Gestió de projecteUpdating Taiga or similar tools.
DocumentacióWriting the documents delivered each iteration.
PresentacióPreparing the oral presentations.

Example row: 2026-10-14 · 1.5 h · Laia · Desenvolupament · US-12 · GET /stations endpoint and integration tests

Taiga: the living backlog

  • Epics group stories; each story has a description, acceptance criteria, points, priority and status.
  • Sprint stories are broken into tasks with an owner, estimated hours and actual hours.
  • Tasks are assigned dynamically, not all at the start.
  • NFRs need a clear place (their own story or acceptance criteria) and must be measurable.
  • Bugs are recorded and, if needed, the affected story is reopened.

A good trick: write in the project report what happens at each event (starting the project, a sprint, a story, starting and finishing a task, finding a bug) and how it affects each tool.

Set up Taiga step by step →

Git and GitHub

Define a branching method (for example Gitflow) and stick to it:

  • main only holds working versions; develop is for integration.
  • One branch per story or task: feature/42-station-map.
  • Pull requests reviewed by someone else before merging.
  • Every commit references its Taiga task: task #42: Add the free bikes filter.

Check your commit messages →

maindevelopfeature/42 task #42 commitsPRv1.0

The methodological aspects that are assessed

These criteria make up 40 % of the project's ambition. Use the list to review how you work before each delivery.

Methodology checklist

0/10

Services between teams

The three teams in a lab group form a circle: A produces a service for B and consumes one from C; B produces for C and consumes from A; C produces for A and consumes from B. Who is which letter is decided at the inception.

  1. Sprint 1: define. Negotiate it: a well-defined, independent feature, general enough to interest both teams (often cross-cutting). Also agree on where it will be deployed.
  2. Sprint 2: offer. Code and tests, an available endpoint and documentation for the team that will use it.
  3. Sprint 3: consume. Integrate your partner team's service.

Agree on the contract early and work against a mock until the real service is up. Generate the contract and the mock →

A B C A → BB → CC → A

Servers, databases and deployment