Sprint Development Work
Last updated on 2026-06-05 | Edit this page
5.1. Introduction
During the Sprint Development time, you will be doing the work required to complete the Sprint Backlog Issues that you selected for the current Sprint, to fulfil the Sprint Goal. Most of this current episode will guide you through the required processes. The remaining sections (after the challenges) are provided as reference materials.
Scrum Masters
As you can imagine, the Scrum Team will be really busy in the limited time for development work. Perhaps you can be in charge of reading the notes and checking that all of the challenges below are attempted. You can also contribute to development work if necessary but your main job is to ensure the Development Team are using the tools correctly and following the Scrum process.
5.2. Selecting and Tracking Your Tasks
Before making changes to any project files, you must claim your work on the project board so nobody else accidentally works on the same thing.
As soon as you pick an Issue (a task) to work on, you must assign your name to it on your team’s GitHub Project and mark its status as “In Progress”.
How many tasks can I put into “In Progress”?
In Agile/Kanban, limiting the number of tasks you are working on at the exact same time is called a WIP (Work in Progress) Limit. To keep your workload manageable, try to have a maximum of one active GitHub Issue in your “In Progress” column at once.
If you get stuck because you are waiting on some other task/Issue to complete, update the GitHub Issue’s status to “Blocked” so you can pick up a different task. Always leave a quick comment on the GitHub Issues explaining why it is blocked. For example, If Issue #12 depends on Issue #5, then in Issue #12 you add a comment: “Blocked by #5”
Challenge 1: Select a task to work on
- Each participant working in the Developer role, select a Task/GitHub issue from the Sprint Backlog, assign it to yourself and mark its status as “In Progress”.
- As you update the status, check the “Current Sprint” view in your team’s GitHub Project. What happens to the location of the Issue on the Kanban board, as its status is updated? You can also update an Issue’s status by dragging it between columns on the Kanban board.
- Only one person should be assigned to a GitHub Issue so ownership is completely clear. If a GitHub Issue feels too big for one person, break it down into smaller, individual GitHub Issues.
5.3. Keeping Your Team Updated
Every GitHub Issue has a
comments box where you can type notes or assumptions. You can also
mention or tag teammates to ask questions by using the @
symbol followed by their username (like @JohnDoe). They
will receive a notification so they can jump in and reply.
Relax: We know you don’t have very long…
This workshop is not about producing a flawless, perfect final product. This is about learning how to use GitHub as a simple tool to track a project and communicate as a team:
- Any mistakes or typos provide great examples of things you can add to the backlog to fix later.
- Any breakdown in team organization provides a perfect talking point for your next Sprint Retrospective meeting.
- Continuous improvement is the main goal!
Challenge 2: Work on your active task and keep it updated
Go to your repository on GitHub and open the file you need to work on for this sprint.
If the file does not yet exist, use the template text to create it (seeGuide: creating .md files directly in GitHub). If you have already created it, use the Pencil (Edit) icon to update/edit it (see how to edit .md files directly on the GitHub in Guide).
Save your work using the green Commit changes button. This acts as a permanent “save point” so the team can track progress.
-
While working on your task, use the Issue comments to:
- Share progress updates
- Record assumptions
- Add any relevant notes or blockers
- Share progress updates
Scrum Masters: Continuously monitor the Kanban board to understand progress and identify blockers. If the team is updating regularly, you should not need to chase updates.
(At minimum, each participant should add at least one comment during the task.)
Mid-Sprint Updates to Requirements
It’s not common for requirements to need updating mid-sprint as sprint duration should be adapted to match the rate of change of Stakeholder needs, but it can happen. For example if there was an urgent update to tackle a security breach or risk. If this does occur, the current active sprint should be stopped and the Scrum Team need to follow the Backlog Refinement process, before starting a new sprint.
(If an urgent change in requirements is announced, see Backlog Refinement Episode: Mid-Sprint Changes)
5.4. Peer Reviews & Completing a Task
Since your Team’s Definition of Done requires a peer review before any task can be marked as complete, you cannot simply move your own GitHub Issue directly into “Done.”
This review checkpoint ensures that your work meets the team’s quality standards, catches simple mistakes early, and keeps everyone aligned before you show your progress to stakeholders.
Challenge 3: Request a review
- If you have finished working on an Issue, update its status to “Awaiting Review” on the GitHub project.
- Open the GitHub Issue’s comment section and tag your teammate by
typing the
@symbol followed by their GitHub username to explicitly ask them to review your work.
Challenge 4: Review, feedback, and complete the cycle
Look at the GitHub Issue with “Awaiting Review” status on your board. If a teammate has tagged you in the Issue comment section, open their Markdown file, switch to the Preview tab, and leave an encouraging comment or an “Approved!” message on their GitHub Issue.
If your work has been approved, update the GitHub Issue status to Done in the GitHub Project.
If changes are requested, move the Issue back to In Progress, update the Markdown file using the edit (pencil) icon, and ask your reviewer to check it again once updated.
- 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.