Key Points

Learning Objectives

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.

A repository should be provided by your facilitator for you to work on during this course.
There is a project template which should be used as the basis of all GitHub Projects.
Some additional setup is required to new repos and projects, specifically the importing of rulesets and the addition of workflows respectively.
Your newly created project can be linked to your repos via their “Projects” tab.

In this course Request document forms the basis for gathering requirements.
We can use the MuSCoW strategy to help Stakeholders to prioritise the list of requirements.
Requirements are broken down into User Stories and Tasks which are added to the GitHub Project as Issues.
The new Issues added to the Product Backlog must to be prioritised, led by the Product Owner.
Issues can be categorised further by using a variety of fields, for example the “Labels” field.
Epics are larger bodies of work, spanning multiple sprints (possibly multiple projects). A custom “Epic” field exists to allow Issues to be assigned to an owning Epic.

At the start of each sprint, there is a Sprint Planning Meeting
The Sprint Planning Meeting is attended by the Scrum Team, Product Owner, and Development Team
The Product Owner ensures that the highest priority Issues are highlighted.
Collectively, the Scrum Team decide on a Sprint Goal that represents what is to be achieved during the sprint.
The Development Team selects candidate backlog items that align with the Sprint Goal.
The Development Team add a story point estimate for each candidate backlog item. One way to do this is by playing Planning Poker.
The Development Team, together with the P.O., agrees on a Sprint Goal and commits to the Sprint by creating the Sprint Backlog.

The GitHub Project board is our visual control center. If a task isn’t updated on the board, the team won’t know it happened!
“Committing” is just the GitHub word for “Saving.” Every save creates a clear history of your progress.
Peer reviews keep quality high and help us catch simple mistakes early before we show our work to stakeholders.

Sprint Review Meetings give the team the chance to demonstrate the latest Product Increment.
GitHub Releases can be used to organise and present completed work.
Sprint Reviews are useful for checking whether the product is meeting the current requirements and to assist with refining the Backlog.

Sprint Retrospective meetings are a safe space for Developers to provide feedback on ways of working and improve the process.
Reviewing past action items ensures continuity, accountability, and progress before planning the next sprint.
Effective retrospectives rely on facilitation, collaboration, prioritisation, and psychological safety to encourage honest reflection.

Adding and prioritising Issues is an ongoing task, known as Backlog Refinement. (AKA “Backlog Enhancement”, “Backlog Grooming” or “Backlog Pruning”.)
The Backlog needs to be fully refined and up-to-date before each Sprint Planning session begins.
Mid-sprint changes to the Sprint Backlog are permitted if it doesn’t change the sprint goal but sometimes in a research environment, the current sprint just needs to be stopped and a new sprint planned as changes in direction can be dramatic!