“Kenapa Sprint Review-nya cepet banget???” A Walkthrough of Scrum Framework

In this article I will help you to understand Scrum framework, one of Agile software development implementations. I will show you how my team PPL Cewe Semua implement this framework in our project and what we learned during the process. Technical terms in the framework will be defined as I walked you through each steps of Scrum events. Before that, I will introduce you to the concepts of Agile software development I got from Mark Shead’s video on Youtube. Lets get started…

What is Agile?

Agile is not a methodology, a way of developing software, nor a framework. Agile is a set of values that the teams use to make decisions on how to develop software. By following these values, it is believed that teams will be able to develop software better. Below is the values and principles according to Agile Manifesto:

Values

• Individuals and interactions over processes and tools
• Working software over comprehensive documentation
• Customer collaboration over contract negotiation
• Responding to change over following a plan

Principles

1. Our highest priority is to satisfy the customer through early and continuous delivery of valuable software.
2. Welcome changing requirements, even late in development. Agile processes harness change for the customer’s competitive advantage.
3. Deliver working software frequently, from a couple of weeks to a couple of months, with a preference to the shorter timescale.
4. Business people and developers must work together daily throughout the project.
5. Build projects around motivated individuals. Give them the environment and support they need, and trust them to get the job done.
6. The most efficient and effective method of conveying information to and within a development team is face-to-face conversation.
7. Working software is the primary measure of progress.
8. Agile processes promote sustainable development. The sponsors, developers, and users should be able to maintain a constant pace indefinitely.
9. Continuous attention to technical excellence and good design enhances agility.
10. Simplicity–the art of maximizing the amount of work not done–is essential.
11. The best architectures, requirements, and designs emerge from self-organizing teams.
12. At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly.

What is Scrum?

According to scrum.org, Scrum is not a methodology. Although it follows a methodical approach, in practice Scrum does not tie its followers to a certain sets of rules. Scrum is a framework that follows Agile values and principles. Below is the image that portrays each events in Scrum framework.

Scrum Framework

Scrum Implementation in sumbang.in Project

Values

1. We don’t rely on tools to be productive
2. Make the code works! Write documentation later
3. Do what the client said, no matter what they said in the beginning.
4. Change always happen, adapt!

Principles

1. We always give the APK of our app to the product owner before Sprint reviews.
2. Adapt to change, I had to change the flow of changing password even if it is different from what we planned in the beginning
3. We have to come up with a finished product every sprint review.
4. Always communicate with the product owner when there are unclear requirements
5. We are a close-knitted group so it was not really a problem to help and motivate each other
6. We have scrum meeting every Tuesdays and Thursdays. We also have a coding marathon each Monday and a day before Sprint review. It helps us to get more productive!
7. We have to make sure to give minimum viable product each sprint.
8. We have a routine we follow each sprints
9. By implementing TDD, we can prevent many undetected errors as our project grew
10. Each sprint we have to make a feasible goal. Move the task to the next sprint if the task is impossible to work on in one sprint
11. My team is always open to each other, ask for help and someone will help you right away!
12. Every sprint retrospective we reflect on what we’ve done in the last Sprint. We give feedback to each other so we can do better next time.

Before Sprint

When developing product we have sets of requirements and goals that needs to be met called product backlog. This product backlog is made by Product owner, the person who represents the final user’s best interest, and has the authority to say what goes into the final product. Product backlog is also called user story.

Lessons learned: Don’t think product backlog as a feature that you can work on over the span of few sprints. If you think a backlog needs more times to work on, break it down to smaller backlogs. Try to make each backlog as independent as possible.

Sprint Planning

Sprint is a predetermined time frame within which the team completes sets of tasks from the Backlog. The length of time depends on the needs of the team, for PPL 2019 we have two weeks to create minimum viable product. Minimum Viable Product (MVP) must be a fully functional product with just enough features to satisfy early customers. This product features will be updated on each Sprint.

Minimum Viable Product Illustration (hackernoon.com)

The MVP of each sprint is defined in Sprint goal, determined by the product owner. When we have the have the sprint goals we can choose the related backlog items from product backlog. This sets of backlog items is called Sprint backlog. Scrum master is responsible for promoting and supporting the implement of Scrum in team. Scrum master helps the development team to break down the chosen backlog items into smaller tasks. The development team will chose what tasks they will do for the Sprint.

Lessons learned: It’s hard for team members to do their job if there are dependent backlogs. Make sure to plan your sprint accordingly.

Daily Scrum

Daily scrum is a quick meeting for the team members to give their progress updates. The team can choose their own time to have daily scrum. The meeting isn’t necessarily daily, for our project PPL Cewe Semua have daily scrum each Tuesdays and Thursdays.

Sprint Review

After the Sprint period ends, the team will presents their work during the period to product owner. During sprint review, product owner will evaluate what has been done and what has not been done related to the sprint goal. Product owner can either accept or reject the product. A product of Sprint is called an increment if the product owner accept the product.

Sprint Retrospective

In sprint retrospective, Scrum master will help the team members to identify what lessons they learned during the Sprint period to improve their productivity for their next Sprints. The team members can have peer review to help each other to understands better. The product of this event is sprint experiment, a set of ideas the team member can try to improve their productivity. For example, my team figured rather than doing one backlog alone, it is best to do pair programming for each backlog.

After Sprint

The Sprint doesn’t end here. Sprint is a recurring process that will only end if there are no more backlog items left in product backlog defined at the beginning of the project. The team members will continue to do sprint planning, daily scrum, sprint review, sprint retrospective, and back again. Each sprint will produce an MVP with incremented features along with each Sprints.