Agile and Scrum Tutorial for Noob Dev Teams
By: Figo Muhammad
Tags: Scrum, Software Development, Agile, Software Engineering, Tutorial

Scrum

As I mentioned earlier, the most common frameworks in the most common frameworks are Scrum and Kanban. If you are interested more in Kanban, I recommend reading about it from the Atlassian website: https://www.atlassian.com/agile/kanban.

Scrum is a framework for developing and sustaining complex products. Scrum has actually been developed earlier than Agile. Scrum enables us to follow several values and principles of Agile if the team successfully applying Scrum. It derives the theory of Agile values and principles into a practice that we can follow, from meetings, tools, and roles.

It is an iterative framework for developing, delivering, and sustaining complex products. Iterative means that the framework has a repetition of activities, a cycle. It is said that Scrum can also be used for other kinds of teamwork, other than software development. That is why Scrum is very popular.

Sprint

Scrum is an iterative framework and uses the so-called sprint cycle which consists of a series of events:

Sprint Planning Daily Scrum Sprint Review Sprint Retrospective and goes back to the first point.

If a team has performed that series of events, the team has performed a sprint. My team often uses the term sprint to mention a single iteration. There is a first sprint, second sprint, third sprint, and so on.

The length of a sprint is flexible, although it must be in a short period. My team has a sprint length of two weeks and I actually have another project that uses the length of one month. It is really flexible, depends on the number of hours the team wants to put into the development.

Roles

All the roles that are going to be mentioned below are not static. A person can have many roles in a team or different teams.

Product Owner

This role is responsible for delivering the most value to the users. A product owner has to understand the users’ needs while still balancing other stakeholders’ needs. A product owner must sort all work items based on the business value considering all the inputs and other factors, more on this later. Then, those responsibilities are poured into a single document/artifact called a product backlog.

Scrum Master

A scrum master is responsible for creating a scrum environment and ensuring the scrum is maintained and done well. A scrum master is also a servant-leader type of leadership that supports all the members of the team. A scrum master helps the product owner understand and communicate the backlog better. For the development team, a scrum master helps the team focus on the outcome and self-organize.

Development Team

This is the team that does the work. It doesn’t only consist of engineers, but others like writers or designers can be in this team.

Events

In each event, there are tools to help each event’s goal. My team and other developers usually call it artifacts.

Sprint Planning

Before this event, the product owner has to define a sprint goal based on the value that he/she seeks considering all feedback from other stakeholders, lessons learned in the previous sprint, and the vision of the product. The product owner also has to define several potential work items that can contribute to the goal. The product owner also has to review the existing work items and readjust it if needed. In Scrum, these potential work items are written in an artifact called a product backlog. This artifact functions as a connection between the product owner and the development team and the product owner have to make sure that every stakeholder can access it anytime.

My project’s product backlog

A product backlog consists of product backlog items or PBI that define the work items. You can make any types of PBI: user stories, bugs, design changes, technical stuff/chores, or anything. The product owner also has to sort the PBIs based on each business value.

Google Sheets is the most simple tool that can be used to make the product backlog. However, you may find trouble in sorting the PBIs. There are alternatives like Trello and others that come with their own advantages and disadvantages.

There is a special template called the Connextra template for the user story type of the PBI that is used by my project team: “As <user>, I want to <activity> so that <goal>”. It helps us in defining the features that are needed by the users to be more clear.

You may want to define acceptance criteria(s) for each PBI for the development team to make it clearer for the development team.

Next, at the sprint planning meeting, the product owners and the development team discuss what PBI(s) that will be taken in the current sprint. The development team “pulls” the PBI(s) based on their velocity of the development and put it/them in another backlog called Sprint Backlog. This backlog is a simple container. In my project, we just highlighted the pulled PBIs with color on their IDs on the product backlog. Note that the meeting’s output is a negotiation of the product owner and the development team. Nobody has to force each other.

After selecting PBIs, my team usually break each PBI down into tasks. Each of them defines what each member must do to help the team completing the PBI. A single task can usually be done in total work hours in the gap of two daily meetings. For example, in my project, we hold a daily meeting twice a week, Monday and Thursday. We define a single task to be a five-hour length. If your workhour are 8 am to 5 pm and you want to hold a daily meeting every day, then a single task should have a length of more or less seven hours.

My project uses the board feature in the GitLab to manage tasks.

Daily Scrum

This meeting is the most frequently performed event in a sprint. The goal of this event is held is to enable members of the team to discuss progress toward the goal. The daily scrum is short, a 15-minute length max. As I said earlier, the daily scrum can be held every day or less, it depends. The team should evaluate their daily meeting in the sprint retrospective to get the most effective amount of daily meetings in a week, more on this later. Its method is also unique to every team.

Sprint Review

It is said that “Product Review” is a better name than “Sprint Review”. In this meeting, members demonstrate the implemented features of the app in the sprint. It is usually held for thirty minutes to one hour in length. The goal of this meeting is to get feedback from other stakeholders. It is also encouraged to celebrate the hard work the team has done in the sprint.

Speaking of done, a team must have a clear definition of done, how a PBI can be defined as done. Making a “definition of done” document can help to make sure each member is on the same page when someone says “done”. It can contain the done definition of code review, testing, deployment, etc.

Definition of Done of my project

Making acceptance criteria as I mentioned earlier in the sprint planning section can also help to define what “done” means in each PBI.

Sprint Retrospective

This is the final event of a sprint where the team:

Inspect how the last sprint has been done, the tools, the relationship, etc. Identify what went well and what needs to be improved Create a plan for the improvements that are going to be implemented in the next sprint.

The Sprint Retrospective is usually 1.5–3 hours. This is one of the key elements of Scrum. This event, if done appropriately, will improve the speed of the development and the quality of the product.

My team uses https://metroretro.io/ in this event as the tool. My team uses the Good-Bad-Start-Stop board. It helps us define what went wrong and what went right. It also helps us define the improvements that can be made in the next sprint. The steps of using the board are:

Make sure all the members hide their sticky notes Set a timer, usually 5 minutes Each member fills the Good and Bad sections until the time runs out. Then, All members show the sticky notes. Scrum master navigates to each sticky note and ask for an explanation from the member who wrote it if needed, Start section first and then Stop. Do step 1–5 for the Start and Stop sections Scrum master makes a summary of the improvements that are going to be implemented in the next sprint in the Actions section.

I encouraged you guys to learn more about Scrum in detail in the links below. This article is just a simple version of the guide.

Summary

Agile is not a methodology or a way to develop software. It is a set of values and principles. To follow the values and principles of Agile, a team can use various tools and frameworks. Scrum and Kanban are the most common framework that is used in the industry nowadays. You can experiment and try new things because every team has its own unique advantages and disadvantages.

I would like to thank Atlassian for explaining Agile and Scrum in their article. It helps me a lot in understanding those topics and writing this short tutorial.