Scrum

At d-centralize, Scrum is used for managing project development.

Product backlog

Every product or service that’s developed within d-centralize has its own GitLab project page. The basic information should be visible there. Each product that’s in active development has at least one Board or Milestone (this is GitLab terminology for product backlog) assigned.

Best practices

Usually, a milestone has a clear focus (one line describing the topic). To stay focused, it should contain at most 1 big (as in complexity or duration) issue. This is often a feature or a refactor to reduce built up technical debt. Experience taught us it’s feasible to add 4 smaller issues implementing minor features or bug fixes. During the course of the roadmap, an additional amount of issues (dependencies of issues that the roadmap started out with) is usually added as a result of new insights.

Creating a product backlog

Select a project in GitLab, browse to Issues, then Boards. Open the board drop-down, select Create new Board. Provide a Name, but make sure you prefix it with Product:. Now create or edit issues that you want to assign to a product backlog.

Sprints

Sprints at d-centralize are held every two weeks and contain at most 10 working days. Each sprint starts and ends with a sprint meeting. A couple of issues from the board that need to be completed with the highest urgency are assigned to a sprint backlog. This provides an opportunity to increase focus and not be distracted by other tasks that may seem important too.

Sprint meeting

At 17:00 on the last sprint day, a sprint cycle is completed. In case there’s a good reason, the meetings can be held more frequently.

Take turns in reviewing the past 2 weeks. Just keep it factual, reflection is later. Everyone participates. Each review is finished off with a technical demo. For fun, to show off, but most importantly to inform your co-workers what you’ve been working on all week. It makes the stand-ups more understandable.
Reflection canvas on a projector. Everyone participates.
Planning for the next 2 weeks. Every project group does its own planning. This is the opportunity to act on these reflections right away.

Reason for holding this meeting:

"Suppose you came upon someone in the woods working to saw down a
tree. They are exhausted from working for hours. You suggest they
take a break to sharpen the saw. They might reply, "I don't have time
to sharpen the saw, I'm busy sawing!"

Make sure to sound the alarms when the meeting starts to look like XKCD.

Creating a sprint

Select a project in GitLab, browse to Issues, then Milestones. Select New milestone. Provide a Name that contains the start and end date of the sprint. Like: 2019.02.05-2019.02.16. Now create or edit issues that you want to assign to a product backlog by assigning their Milestone to the chosen sprint.

Assigning work

An issue can be assigned to one or more project members that become responsible for completing the issue (or rejecting it) through the Assignee field.

When help is requested outside the project team, special purpose labels can be assigned to an issue through the Labels field.

Task Label Board

Design UI/UX design project

Office office office project

These tasks end up on the board of the Design or Office management team where they’ll be prioritized and planned in any future week. In case of urgency, communicate that by assigning the Due date in the issue.

Definition of Done

To be able to mark a certain task from the backlog as “done”, it needs to meet a definition of done, DoD in short. That way there can be no discussion about what “done” means. Does it tick all the boxes? Then it is done!

Each project should have its own DoD defined, and the one below will go as default if a project does not do so. New projects can use the list as a base for their definition of done.

note: the DoD below assumes that “tasks” on a backlog are defined as user stories.

[ ] Code Review should be done and agreed on.
[ ] No new linting errors.
[ ] Project should build and generate valid code that can be deployed elsewhere.
[ ] It must be possible to demo a user story.
[ ] Implementation needs to be checked and accepted (by someone else than the author of code).
[ ] Internationalization should be applied (no hard-coded text allowed).
[ ] Mobile first approach, it should work on mobile / tablet and desktop.
[ ] All tests should run and pass.
[ ] Keep code coverage as high as possible. 100% preferably.
[ ] Migration schema’s for data.

Daily Scrum

Every day we’re actually standing up and take turns while stating the following:

What have you completed since the last stand-up?
What do you plan to complete by the next stand-up?
What is getting in your way?

Reasons for holding the daily:

Share information among peers.
Make sure no-one gets stuck on things for too long.
Keep track on meeting the Sprint Goal.

Daily Scrum Etiquette

Passing the stick

During the Daily Scrum it is necessary that everybody that is present gets their fair turn. In order to keep a nice flow it is very helpful that, when you are finished with your part, you state the name of who gets to speak next: aka passing the stick!

Let’s try to stay out of the pitfalls.

The time each project or team will do its Daily Scrum is to be defined with the team or project itself. Most preferably it is being held as early in the morning as a way to get the day started.

Some teams will not be able to meet physically. It is preferred to do the meeting via video conferencing. While doing so, keep in mind to stick to the general rules of a Daily Scrum. It is supposed to be a 15-minute time-boxed event for the development team. Standing up as a team helps to have a short meeting and also takes away the distraction that you have while sitting behind your computer. So make sure you can focus on the meeting and don’t continue to work while listening to your coworkers.

Communication

Since we’ve evolved to a company where work is being done remote as well as in office, you no longer hear everything that’s going on around the coffee machine. Every team member doesn’t naturally know everything anymore and each team members needs to put more effort in sharing knowledge, feelings and progress.

Mattermost is our default way of communication, but don’t rule out e-mail, your mobile phone or video conferencing. Whatever works for the team.

Before the sprint starts

At the time a sprint starts, speak up if you think it’s not realistic and probably don’t meet the deadlines. It’s better that everyone involved knows this as soon as possible and the sprint goals can still be changed.

During the sprint

Communicate with your team members if you think you won’t finish all planned work for this sprint. Something might be more difficult in practice, you may be blocked on input from others. If team members are counting on your delivery at the end of the sprint, speak up and let them know. Find a solution together.