Scrum

Our guidelines for how we do Scrum

Task board

The task board encompasses all the ongoing projects of the team and is managed using Waffle.io. The board is divided into the following stages:

• Backlog
  This is where items of the product backlog are kept and is odered by the product owner. All new GitHub issues opened in repositories of the team will show up here.

• Ready
  When an item is ready for a sprint and a developer has signed up for it, it will be moved to the "Ready" stage and assigned to the GitHub milestone associated with the sprint. GitHub pull requests will start out in this stage. The item is then to be given an estimate after which the developer can proceed to work on the item.

• In Progress
  Once a developer starts working on an item it will be moved to the "In Progress" stage. It is the responsibility of the developer to update the estimate of the item as they progress their work.

• Review
  Once the developer considers an item done it is moved to the "Review" stage and assigned a GitHub label of either major, minor, or patch according to Semantic Versioning. The developer must then unassign themselves from the item. Another developer will then be chosen and assigned to perform a code review. If the item is not approved, it must be re-assigned to the original developer and be sent back to the "In progress" stage.

• Accept
  Once an item has been approved in the "Review" stage, it will be moved to the "Accept" stage for final approval from the product owner.

• Done
  Once an item is considered done according to the Definition of Done it will be moved to the "Done" stage either by closing or merging the item or manually moving it on the board.

Estimation

The following Fibonacci point scale is used for estimating the work required for completing a backlog item:

Points	Meaning
1	Can solve the issue by researching a little
2	Can solve the issue by researching a medium amount
3	Can solve the issue with a little bit of pair programming or a lot of researching
5	Can solve the issue with a lot of pair programming
8	Issue is not divisible, but is very complex, i.e. requires group work
13	Issue can most likely be subdivided
21	Issue must be subdivided into at least two issues
34	Large issue, must be subdivided into several issues
55	User story should most likely be revised as it encompasses a lot of issues
89	Ambiguous user story that must be revised as it encompasses too many issues to be divided as-is

Development

Development of an implementation of a backlog item is carried out in accordance to GitHub Flow with some additional requirements and tooling support. One of the primary requirements of the development workflow is the use of protected branches in order to enforce the workflow and ensure the integrity of the main product branches.

Workflow

1. Create a topic branch
   All work is to be carried out on topic branches to ensure isolation. Make sure that the name of your branch describes the work you'll be doing and that it's written in kebab-case (eg. my-topic-branch).

2. Add commits
   Once your topic branch has been created you can start making the desired changes. Make sure to keep each commit small in order to allow for easy reverts which can and will happen. It's a good idea to use a GUI client when committing to ease staging patches. Also make sure to familiarize yourself with the seven rules of a great git commit message.

3. Create a pull request
   When you've committed and pushed some work it's time to create a pull request against the main product branch. Follow the same guidelines for writing pull request titles and descriptions as you would for commit messages and assign yourself to the issue. If your pull request resolves an existing issue then make sure to state this in either the title or description of the pull request using the corresponding keywords to associate the pull request with the issue. Once created, your pull request will show up in "In Progress" stage on the task board. Keep in mind that you can continue committing to your branch after the pull request has been created.

4. Assign a developer for a code review
   Once satisfied with your work it will need a code review from another developer. Move the pull request (or its associated issue) to the "Review" stage on the task board and unassign yourself. Once a developer has been chosen for reviewing the pull request then assign to the pull request to them.

5. Implement feedback from the review
   If the code review finds anything that needs to be changed then implement and commit the changes to your topic branch. This prompts another review so repeat step 4. If nothing is found and the work is approved then proceed to the next step.

6. Squash commits
   Now that the code has been finalized it's time to rebase and squash all the commits of your topic branch into a single unit of work on top of the main product branch. If you're not entirely comfortable with rebases it's a good idea to get another developer to help you out.

7. Assign the product owner for final approval

8. Merge the pull request
   Your pull request is now ready to be merged into the main product branch; well done! 🎉

Reviewing

After finishing an implementation of a backlog item it must go through a lightweight code review performed by a developer different from the one who implemented the code. The developer performing the review should ensure that:

• The code is tested
  Check that the code is sufficiently tested and that the implemented tests adhere to the specification of the item being implemented.

• The code is performant
  Within reason, check that the code doesn't contain any known performance pitfalls. If you know of a better way of doing something then suggest it and ideally back it up with a benchmark.

• The code is understandable
  Check that the code uses sufficiently descriptive function and variable names and is commented appropriately. Other developers will need to read the code down the line as well and must be able to understand it.

• The code is well-documented
  Check that publically exposed APIs are fully documented as these will be used by other developers who are likely unfamiliar with them. Internal APIs should be sufficiently documented as well.

• The code is consistent
  Check that the code fits in with the rest of the codebase and follows the code style conventions laid out by the team. Just like in collaborative writing it shouldn't be possible to tell which developer implemented which code by simply looking at it.

• The code minimises duplication
  Check that the code doesn't add unnecessary duplication and instead reuses code where possible and appropriate.

Increments

Once a potentially shippable increment is ready as the result of a finished sprint, the associated product should have its version incremented according to Semantic Versioning.

A GitHub release is then to be created with a high-level description of the changes made during the sprint and a changelog reflecting the exact items finished. Both the tag version and release title must be the product version prefixed by a single v (eg. v1.0.0). The following template is to be used for the release description:

This release implements some new feature and fixes various bugs.

### Changes

- #1 Implemented feature xyz
- #2 Fixed bug caused by xyz

[`v1.0.0...v1.1.0`](https://github.com/org/repo/compare/v1.0.0...v1.1.0)

License

This work is licensed under a Creative Commons Attribution-ShareAlike 4.0 International License