PPL 2020 — Document Builder: Scrum Implementation in Our Team

Ivana Irene Thomas
pepeel
Published in
4 min readMar 9, 2020

This post is written as a part of individual review criteria of Fasilkom UI’s software engineering project course: PPL 2020

Document Builder’s client (from FHUI), product owner, scrum master, and the code monkeys (development team) in no particular order

Hi all, in this post, I’m going to write a little bit informally and more experience-based but will still try to make it informative about the Scrum Implementation in our team during the course PPL 2020.

First of all, before we dive deep into the implementation, let’s review what exactly is Scrum.

What is Scrum How It Can Help Your Team

We often see the word “Scrum” and “Agile” paired together as if they are connected. Well, the fact is, yes they are. Scrum is a framework that is the implementation of an Agile process.

Let’s make it simple with bullet points:

  • Agile — Development methodology based on iterative and incremental approach
  • Scrum — A framework that is one of the implementations of Agile process

Scrum Theory

Scrum is founded based on the theory that knowledge is gained from experience and making decisions based on what is known. This theory then becomes the foundation of the three pillars of Scrum: Transparency, Inspection, Adaptation. These pillars can come to life when the Scrum values are implemented. These values are commitment, courage, focus, openness, and respect.

Scrum helps a team work together by providing a framework that encourages each of the members to learn from their experience, self-organize, reflect on what’s good or needs improvement and make the team continuously improve.

Our Implementation of Sprint in Scrum

Sprint is a short, time-boxed period when a scrum team works to complete a set of tasks or product backlogs. In PPL 2020, each sprint is time-boxed to be two weeks long.

In each sprint, there are four main activities that we do:

  1. Sprint Planning

Sprint planning is the first activity done in a sprint. There are two main items that need to be communicated in the sprint planning: what we’ll do this sprint and how it can be done. In sprint planning, we define the product backlog items (PBI) that we’re going to do and break them up to multiple tasks. We do these by taking items from our Product Backlog Items spreadsheets defined before the sprint starts by the product owner, break them up to tasks, put them on Gitlab issues board, and assign the people that will do the task.

Complete list of all PBIs from the start to the end of product development
Gitlab issues board that contains broken up tasks from PBI

2. Daily Standup

The daily standup is there to keep the team informed, updated, and aware of the team’s progress. In PPL, standup meetings are done at least 2 times a week, and that is 4 times per sprint. In every standup meeting, we gather and do a short face-to-face meeting updating our progress and keeping everyone in check. The format that we usually do in our team is for every single of us to talk about:

  • What they’ve done/are doing
  • What’s the progress
  • What they’ll do until the next standup
  • Whether there is any blocker

Please keep in mind that the daily standup is supposed to be short (usually 10–15 minutes, 30 minutes max) and is not supposed to be used for planning (Planning should already be done in the sprint planning).

3. Sprint Review

Fast forward to the end of the sprint, the sprint review is conducted at the end of the two-week sprint. In this sprint review, we give a presentation to our client showing what we’ve done so far. We explain which product backlog items that we do in that sprint, and what’s the result. By the time the sprint review is conducted, a working product that meets the definition of done should already be deployed to the staging server and be presented. During this review, if a product backlog does not meet its definition of done, the PBI can be rejected, the changes have to be reverted, and the item should be carried over to the next sprint.

Our team while trying to hack our way to meet the definition of done, one day before sprint review

3. Sprint Retrospective

In sprint retrospective, the team gathers to reflect the past to improve the future. I personally feel that this process is really beneficial for us individually and as a team. In this activity, we discuss the following things:

  1. The good things that happen during the sprint
  2. What went wrong during the sprint
  3. What we should stop doing moving forward
  4. What we should start doing moving forward
  5. What are the action items

We use the tool metroretro.io where each of us sticks virtual sticky notes on the board on each of the items:

Sprint Retrospective with the help of metroretro.io

That concludes our team’s experience using scrum during PPL 2020 and finishing our first sprint. Our first sprint was thankfully a success with all the PBIs meeting the definition of done and none rejected (YEaYyY).

Thank you for reading, I hope it was useful!

Reference

--

--