Wednesday Week 5


So far, we’ve worked on git individually

For the next two weeks, you’ll work in pairs

When working with others, we review one anothers’ code and merge it into the main branch

Code review

Learn by reading others’ code

Developers generally spend more of their time reading code than writing it

On the apprenticeship programme, you’ll review another team’s code each week

On the pre-apprenticeship, you’ll review each others’ pull requests




A widely-used software development method, that uses some of the terms below


A fixed period of development time during which the team will not respond to new change requests

Sprint length

Two weeks is typical in the industry. During the pre-apprenticeship we will work in one-week sprints. During the full-time programme, each week we are going to do a single two-day sprint. For your final project, you will be doing one-week sprints.

User story

An action that a user wants to perform

User story

“As a… I want… So that…”


All uncompleted user stories

Sprint backlog

A prioritised backlog of all the user stories that we estimate will be completed in the next sprint, given each user story estimate and the team’s velocity

Sprint planning

Where the team reprioritises user stories and agrees the next sprint backlog

Sprint retrospective

Stop, go, continue

Sprint review

Where the team compares their points estimate of each user story with their actual points and adjusts their estimated velocity for the next sprint


The team capacity, expressed in points, for each sprint


The difficulty level of a user story, expressed in points


Some people prefer to estimate in absolute time, expressed in hours or half-days, but in order to develop a good sense of relative time, we will estimate our user stories in points

Issue labels


  • E1 - Short story, estimated
  • E2 - Story, estimated
  • E3 - Long story, estimated
  • E5 - Extra long story, estimated


  • A1 - Short story, actual
  • A2 - Story, actual
  • A3 - Long story, actual
  • A5 - Extra long story, actual

Issue types

  • story
  • chore
  • bug
  • refactor
  • spike

Project board

“Kanban” which you are going to use to track your project


Not all issues raised in the project board contribute to the velocity estimate. Chores, bugs, refactors and spikes are all zero-point issues, even though they will (seriously) impact your sprint velocity.

Zero-point issues

  • Chore Something that needs to be done, not directly related to a user story
  • Bug Something broken
  • Refactor An improvement to the code that delivers no change to user experience
  • Spike Researching a potential solution to a problem by creating the simplest possible implementation of it


Some people prefer to estimate chores, bugs, refactors and spikes just like user stories, however they might better be thought of as non-negotiable and therefore outside the scope of the sprint planning process.


  • Scrum™
  • Sprint
  • User story
  • Estimate
  • Velocity
  • Backlog, sprint backlog
  • Sprint planning, retrospective and review
  • Project board (Kanban)