Skip to content

How to sprint at Beautiful Canoe

In Beautiful Canoe, all project work is broken down into sprints, which:

  • run company-wide, that is, all projects start and end their sprints on the same day;
  • (usually) last for two-weeks;
  • start with a rough plan, based on the priorities of the client;
  • include a release, either to a staging server or production server,
  • end with a retrospective.

Before the sprint

Before each sprint a new milestone should be created for that sprint in the beautifulcanoe group and the traffic3d group. There should be no project-level milestones in the company.


Sprint milestone must have start and end dates, so that the automated sprint tools that we use at the end of each sprint can run correctly.

The Scrum Master (usually @snim2 or @a.garcia-dominguez) should ensure that each project has an accurate, up to date, and correctly triaged issues board.

In particular, any issues that were left unresolved from the previous milestone should be rolled over to the next sprint.

How to start a sprint

Each sprint begins with a planning sessions. Each project should have its own session, which should take place between the project developers and BC Scrum Master. The sprint plan should be based on:

  1. the priorities of the client, as expressed in the most recent meeting.
  2. the long term need to avoid or tackle technical debt.

Planning meetings are driven by the issue board for the project, which should contain the user stories and bug reports for the project. In order for planning meetings to be useful, and for the needs of the project to be accurately represented, issues lists should be kept up to date, and correctly labelled. The issues boards for beautifulcanoe and traffic3d should be an accurate representation of the status of each project, at any given time.

By the end of the planning meeting:

  • issues to be resolved in the current sprint should be labelled ~"To Do";
  • issues to be resolved in the current sprint should be marked with the current milestone;
  • each issue labelled ~"To Do" or ~Doing should be assigned to a Developer;
  • most relevant issues should have a priority label.

The ~"To Do" list should not extend beyond the time of the current sprint, and care should be taken not to overload each developer.


Developers should remember that sprint planning is intended to set priorities and coordinate team members -- it is not a target to reach, and no one should work overtime to "finish" the work in the backlog.

Planning poker

Optionally, sprint planning may use planning poker. This is an agile tool, whereby team members bid for how long they believe each issue will take to resolve.

The Scrum Master should chair planning poker, and not take part themselves. The chair, the client, or someone representing the client, should give an overview of each user story or issue, and this should be discussed until each team member feels they understand the story in full. At this stage, numbers and estimates should not be discussed.

Next, each developer offers an estimate for how long they believe the issue will take to resolve. Since Beautiful Canoe sprints only last two weeks, it is sensible to give estimates in hours. If every team member believes that the issue cannot be resolved in a reasonable number of hours, the issue should be labelled ~Tracking issue and broken into smaller sub-issues. Each estimate should be a number of hours in the Fibonacci sequence:

1, 1, 2, 3, 5, 8, 13, 21, ...

Developers should reveal their estimates at the same time. There are a number of planning poker tools and apps which enable this, but the simplest technique is for each person to hold up a number of fingers representing their estimate.

Developers with very high or low estimates are given a chance to justify for their estimate and discuss them with the team. Discussion should continue until the team has reached a consensus. The developer who is most likely to be assigned to the issue has the largest portion of the consensus vote.

During the sprint

During the sprint each developer is responsible for resolving the issues that they are assigned to, using our usual process. However, sprint plans are not set in stone, they are living documents that should be reviewed and updated (with the Scrum Master) as the sprint continues.

Developers should ensure that the issues and merge requests that they are working on are correctly labelled, so that the whole team can coordinate well.

Developers are encouraged to pair on their issues at any point, if they find that style of development useful.

If it seems likely that the original sprint plan over-estimated or under-estimated the amount of work that could be completed, or if the client changes their priorities, the issues board should be updated. The Scrum Master should regularly review the progress through the current milestone and re-evaluate the backlogs and estimates where appropriate.

The feature freeze

On the Wednesday afternoon of the second week of the sprint each project should hold a feature freeze. At this point, a deployment to the staging server should be made, and the client should be informed. From this point to the end of the sprint, only ~"Hot Fix" changes (primarily ~Bug fixes and improvements to ~Documentation) should be made, and work on the rest of the backlog should stop.

Every member of the team, including the client and Scrum Master, should QA test the new features in the staging environment. A new ~Tracking issue should be created, to keep track of changes that need to be made before the release candidate can be merged into the master branch. This issue is a good example of a tracking issue for a release candidate.

How to end a sprint

Ideally, a sprint will end with a deployment to the production environment on the master branch. In this case, a new issue should be raised in the project, to backport ~"Hot Fix" changes from the release branch (or, exceptionally, the master branch) to develop.

This will ensure that develop is kept up to date with all changes that the client will see in the production environment.

How to reflect on a finished sprint

At the end of the second Friday of the sprint, after any relevant deployments have been made, a whole-company retrospective will take place. To prepare for this, the Scrum Master should run the retrospective bot which will create an issue in the Team Retrospectives repository which will summarise what happened during the sprint.

To run the bot, see the instructions in the retrospective-bot repository. The issue generator can either be run as a manual pipeline on that repository, or as a command-line task:

git clone
cd retrospective-bot
bundle install --path=vendor/bundle
bundle exec ruby retrospective.rb \
    --dry-run \
    --token=${SECRET_TOKEN} \
    --milestone="2019.1 Sprint"
    --group=${TRAFFIC3D_GROUP_ID} \

The secret token can be obtained by either looking at the CI/CD variables in the repository, or logging in as @bc-bot and looking through the Personal Access Tokens in his settings. The group ids can be obtained either from the CI/CD variables in the repository, or from the group pages on GitLab.

Once the sprint is over, @bc-bot will label issues that are still open, with a label such as ~Missed:2019.1


Developers should remember that issues are labelled to help with sprint planning and estimation -- an issue that is rolled into the next sprint is not a judgement on the ability or competence of the assigned developer.

This issue is an example of a retrospective summary. This summary information should feed into a face-to-face retrospective, and can be used to generate summaries of new features and bug fixes to report back to clients.

Any style of retrospective may be used, but each session should be a safe space for team members to discuss their reflections on their work in a non-judgemental atmosphere.

Every retrospective should result in a concrete set of actions that team members have chosen to act on. These next-actions should be recorded in the discussion on the sprint summary issue.

Further reading