# data[].attributes.body
Prioritisation of interactions:

Use of a physical kanban with sticky notes when teams are on site.

Remote continuity:

Multiple Gitlab boards that can be customised by the teams.

In addition to enabling remote sharing, Gitlab boards have the advantage of enabling US to be viewed in columns according to specific criteria:

developpers assigned

workflow (Sprint, backlog, in progress, Done, to test, etc.)

tags (thumbnails created and affixed by the team)

Sprint

# data[].attributes.body
Design (to be carried out by the development team, when the us is taken over)

In the description, write:

As {actor}

I can {achieve}

in order to {gain business}.

Add acceptance criteria (Customer+Techniques)

Analyse dependencies (US diagram with <<include>> and <<extend>>)

Create mock-ups

List the operations to be performed (tasks)

Document interface dynamics (kinematics)

Mark the US with the ‘In progress’ label

# data[].attributes.body
IT Courses:

Creation of a web application dedicated to banking management

# data[].attributes.body
The concept of DoD and its importance are explained.

A general outline is given.

Each team is then free to develop it as it sees fit.

# data[].attributes.body
Drawing up the Product Backlog

Step 1 (By team) :

Identification of requirements expressed in the form of user stories US (Digital Brainstorm)

Each US is not yet written in the form :

as...

I can...

In order to...

but only with :

code Title

Step 2:

Summary of the different needs identified by each team.

Use of the INVEST matrix to determine the admissibility of each US.

The initial backlog is therefore common to all the teams, but they will each be able to develop it differently afterwards.

Step 3:

Prioritisation of backlog items :

Assessment of the story points awarded to each US using online planning poker (whole group)

Story points are awarded on the basis of 2 criteria:

business value

complexity (scope of the work)

Step 4:

Categorisation of items (tag per part), for a better future distribution of tasks, avoiding collisions.

# data[].attributes.body
The teacher checks :

As PO, the consistency between the choices in the sprint backlog and the objective defined by the team in the context of the sprint.

As a SM :

Feasibility

Consistency in the allocation of tasks

Absence of collisions: dependent/linked/blocking tasks

The number of sprints and duration of each one are determined by the teacher.

# data[].attributes.body
The teacher takes on the role of PO and rescue SM.

Within each self-organised team, a SM is appointed and possibly a PO (if one of the students feels that he or she has the necessary business approach).

# data[].attributes.body
Teams are freely composed, only the number of members is imposed (from 2 to 4 students).

# data[].attributes.body
GitLab progress chart (Main board)

# data[].attributes.body
The Merge Request consists, for a developer, in requesting that his work on a US (from a work branch) be added to the sprint's product increment.

This request will enable :

A series of automated checks (tests, conflict checking).

A request for a code review from other team members (at least 2 required).

The code review encourages emulation within the team, harmonisation of practices and of the business approach, and better knowledge of the increment produced.

# data[].attributes.body
Giving a committed speech in front of an audience at the MoHo.

Technician's Certificate in Notarial jobs

Interdisciplinary project between the General Culture teacher and the library teacher.

Project in partnership with the MoHo, Europe's leading collider, for the ‘Positive Impact D-Day’ event.

# data[].attributes.body
All the criteria to be checked to consider a US Done :

Code review carried out

User story acceptance criteria all validated

Tests finalised and accepted by product quality stakeholders (QA -Quality Assurance-, PO, developers)

Documentation updated

Graphic mock-ups respected

Delivered on a stable environment

# data[].attributes.body
During this Sprint planning meeting:

Each self-organising team must:

Define the objective of the sprint

Based on this objective, select the US to be processed from the Backlog (to define the Sprint Backlog), taking into account the story points (priority to units with high added value)

Each developer takes responsability for US in a concerted manner, avoiding collisions with other US (cf. step 4 of the Sprint Backlog):

Identify the tasks for each US

Has his/her choices validated by the team, the SM and the PO

# data[].attributes.body
Product Owner (PO): Library teacher

Scrum Master (SM): General Culture and Expression teacher

Authors : The students

# data[].attributes.body
initial version (example)

Web application for budget management.

# data[].attributes.body
C ontinuous I ntegration/C ontinuous D elivery

CI:

Continuous integration consists of checking, when a developer merges code, that their work integrates correctly into the product (avoiding regression) through the automated execution of tests (unit, integration, functional).

Continuous integration can also carry out code standardisation processes.

CD :

Continuous deployment involves automating the deployment or release to production when a new feature is merged, to enable the customer to follow product developments as soon as possible.

CI/CD is implemented by DevOps teams.

# data[].attributes.attachment_link.title
PlanITpoker: Online Scrum planning poker for Agile project teams

# data[].attributes.attachment_link.description
PlanITpoker is a cool on-line planning poker app that helps Agile project teams estimate projects easily. With a one click signup and always free, Try it today!

# data[].attributes.body
Distribution among developers.

# data[].attributes.body
Main topic: "Happiness at work" around the issue: Can we / should we be happy at work?

Secondary topics: inclusion and digital transition / inclusion and climate transition

Product: a committed speech (plea)

Players: The audience for the speech -> vocational high school students also working on the theme of work / other students in the class / teachers / MoHo staff.

Authors: Students in notarial jobs

Target skills for:

searching for and evaluating information

expressing oneself orally: posture, body language, intonation

dynamism

defending one's opinion and arguing

quality and richness of the French language

organisation: respecting the time allowed, deadlines, the context of the oral production ("D-Day of Positive Impact" Event), etc.

Duration: From December to February

# data[].attributes.body
1 day after the Sprint Review, the retrospective enables the team to question its practices and improve them.

Method used in our case: the 4Ls

For each milestone, the team identifies :

For each milestone, the team identifies :Liked points

Negative points (Lacked)

Aspirations (Longed)

Learnt

# data[].attributes.body
Assessment grid as a means of checking.

# data[].attributes.body
US inputs with weight (story points) in GitLab (collaborative development tool)

See https://gitlab.com/

# data[].attributes.body
Sprint 1: 01/12 - 16/12

Example : Research / Choice of topic

Sprint 2: 16/12 - 06/01

Example : Drafting the structure

Sprint 3: 07/01 -20/01

Example : Writing

Sprint 4: 21/01 - 30/01

Example : Oral training

Sprint 5: 10/02:

"D-Day of Positive Impact" speech at the MoHo (product delivered)

# data[].attributes.body
For monitoring purposes, an online collaborative tool (Padlet) is used to :

upload resource documents

annotate work

Check the progress of work.

# data[].attributes.body
The aim is to draw up an action plan to improve practices in subsequent sprints.

Action plan for the project retrospective on 18 Oct. 2024 :

Seek help as quickly as possible on a US

Work on the issues at home outside the sessions

Consult the Product Owner for the naming of the US

Better planning of US for better support

Communicate more effectively within the team

be productive outside the classroom

make better use of AI and intensify the use of documentation

Code sharing, better team cohesion,

Use of AI in case of problems.

pull the main more often to have less conflict

consult with the team before pulling into main to avoid losing code

Communicate within the team to resolve the problems identified

conduct more frequent internal reviews

# data[].attributes.body
Step 1: In several groups

Users = audience (pupils, students, teachers, MoHo staff)

Identify US needs: what does the audience want from our speech?

What do I want from my speech?

Step 2: Whole class

Summary of US needs

Step 3: Prioritisation of needs

As a speaker, I want to...

find a thesis that is important to me and that I want to defend with conviction.

produce an organised, convincing and well informed speech.

practise using non-verbal communication techniques to enhance the impact of my speech on the audience.

manage my speaking time effectively so that I stick to the time available for my speech.

get feedback on my speech from my peers to identify areas for improvement before the public presentation.

be proud of what I have achieved.

As a member of the audience, I want to...

be convinced, moved

learn more about the "world of work" and "happiness".

to be able to form my own opinion on the subject.

have the opportunity to ask questions after the speech to clarify or debate issues.

have a great time.