Outline and Agenda
Last updated on 2026-06-08 | Edit this page
This workshop focuses on GitHub as an Agile Project Management tool
NOT as a software engineering platform.
During the workshop you will practice:
- Planning and tracking work using a Scrum-style Kanban board (GitHub Project Board)
- Creating and managing Product Backlog Items (Issues) on GitHub
- Defining Epics and User Stories on GitHub
- Organising work using labels, statuses, and workflow columns on GitHub
- Collaborating through issue comments and @mentions on GitHub
- Applying the Definition of Done (DoD) on GitHub
How you will use GitHub repositories:
You will use GitHub repositories to store recipe Markdown (.md) files, working directly in the GitHub browser interface.
We will NOT be teaching:
- Repository cloning
- Branching strategies
- Pull Requests (PRs)
- Merge conflict resolution
- Git command line tools
Why?
The focus is on Agile project management within a one-day course.
- Participants come from different backgrounds
- We want to minimise technical overhead
- The focus is Agile delivery and collaboration using GitHub — NOT software engineering workflows
1.1. Outline
You’ll be working as part of a Scrum Team for the duration of the course, completing a short micro-project together. The way roles are assigned is intentionally flexible so that you can reflect on how Scrum might be introduced and adapted in your own teams.
Roles will be guided as follows:
Scrum Master (rotation-based): If you have a background in project management or coordination, you are encouraged to take on the Scrum Master role. If more than one person fits this description, you can rotate this responsibility between sprints so everyone gets a chance to experience it.
Developers (default role): All participants will primarily work as Developer, focusing on delivering tasks, collaborating within the team, and contributing to the sprint goals.
Facilitator / Product Owner: In this course we include participants acting as a Facilitator. This is not a formal Scrum role, but for the purposes of the course, the facilitator will take on a Product Owner like responsibility, representing a research team (i.e., Stakeholders), who are only “lightly engaged” with the process, and will help you clarify requirements as needed. There will also be an opportunity for you to step into a Product Owner role during selected challenges, reflecting situations where you may need to interpret or represent stakeholder needs in practice.
1.2. Agenda
| Time | Item |
|---|---|
| 9:30-10:15 | GitHub Setup and Familiarisation |
| 10:15-10:25 | Coffee & Questions |
| 10:25-11:15 | Requirement Gathering/Product Discovery |
| 11:15-11:40 | Sprint 1: Planning |
| 11:40-12:05 | Sprint 1: Development Work |
| 12:05-12:15 | Sprint 1: Review |
| 12:15-12:25 | Sprint 1: Retrospective |
| 12:25-13:05 | Lunch |
| 13:05-13:15 | Backlog Refinement |
| 13:15-13:40 | Sprint 2: Planning |
| 13:40-14:00 | Sprint 2: Development Work |
| 13:00-14:10 | Sprint 2: Review |
| 14:10-14:20 | Sprint 2: Retrospective |
| 14:20-14:30 | Coffee & Questions |
| 14:30-14:40 | Backlog Refinement |
| 14:40-15:00 | Sprint 3: Planning |
| 15:00-15:35 | Sprint 3: Development Work & Introduce Mid Sprint Requirement Changes |
| 15:35-15:45 | Sprint 3: Review |
| 15:45-15:55 | Short break |
| 15:55-16:05 | Sprint 3: Retrospective |
| 16:05-16:20 | End to End Demo Facilitator (Branch → PR → Review → Merge) |
| 16:20-16:30 | Day Recap & Close |
1.3. Scrum Development Cycle Overview
As we explained in the Agile Fundamentals Course, Scrum encourages the mindset where change is the norm and enables teams to embrace and respond to change effectively in their work. The Scrum methodology fulfils this philosophy by using Sprint Cycles. Each Iteration (sprint) lasts 2-4 weeks, and gives the Stakeholders and Product Owner a chance to update priorities for the following sprint.
1.4. Scrum Roles
The following slide from Agile Fundamentals – Introductions Part 1 highlights the key Scrum Roles, but in practice we often adapt Scrum roles to reflect how research projects actually operate.
For example, in our RSE Department at the University of Manchester, we loosen the definition of Scrum Roles in our RSE version of Scrum. For example, our Grade 7 Scrum Masters would assume a level of responsibility for delivery that would normally be held by the Product Owner. Also, the Product Owner role might be done by the Scrum Master, Developer(s) and/or members of the academic team, depending upon the project size and level of engagement by the academics.
- You will be working on a Scrum Team of Developers.
- All participants will fulfil the Developer role at some point.
- Participants with project management responsibilities will also take on the Scrum Master role during the course.
- The Facilitator is a role specific to the training course and will assume the Product Owner role throughout the workshop, although you will have the opportunity to temporarily act as a PO through specific challenges.