· 7 min read ·
Software development has gone through a sea of change from the early days. From Architecture patterns to development frameworks, things are always changing. Waterfall, SCRUM, Agile, Lean, Extreme Programming (XP) andKanban are terms you will encounter if you stay long enough in software development. In this blog we will give you an overview of Scrum.
Scrum is a framework! It is often referred to as the Scrum methodology but that isn’t very accurate. Scrum helps people work together to solve problems. Software companies all over the world use scrum to deliver incremental improvements that bring value to users.
Before Scrum, it was hard to find a framework that took into account the changing needs of the business. The older frameworks and methodologies were too rigid. Product development was treated like a giant blob and users saw improvements at a slow pace. Scrum enabled companies to provide faster incremental improvements to users.
A Scrum team is a small group by design. The following roles make up a Scrum team:
A product owner is responsible for maintaining the product backlog. The backlog is a collection of items that the development team needs to work on. It is prioritized so that the team can focus on the tasks that bring the most value to users. The product owner is the representative of the product team in Scrum. They are responsible for clarifying any questions that the development team might have. Questions can be about:
The Scrum Master is the torch bearer of Scrum in the organization. They make sure that everybody feels supported in the Scrum process. Whenever issues arise it is their role to get the team together to find solutions. They coach the organization to get better at applying the Scrum framework. They make the development process transparent for all the stakeholders.
Developers focus on making incremental product improvements in each sprint. They play a key role in planning the sprint. The product owner identifies items that need development effort in order of priority. The developers then bring in work into their sprint that they can commit to delivering by the end of their sprint cycle.
Scrum defines the roles and responsibilities very clearly. But in reality your company might not have all the roles. For example a lot of smaller companies don’t have Scrum Masters. In such cases the product owner and engineering manager lead the team to follow the scrum guidelines. Some companies don’t have product owners. They might have a product manager or business analysts or both. In some cases product managers create user stories and the engineering team breaks it down further during sprint planning. The point here is that the “title” does not matter if people with the right skills are doing the right work.
In this section we will go over things that make up a SCRUM. Before we get into the specifics let’s talk about the most important thing. Scrum team names!!! 🤣🤣. Get everyone together and let their first team building exercise be picking up a team name.
A sprint is a time bound recurring event during which developers work on making incremental updates. The length of sprints can vary between one to four weeks. The length of the sprint should be long enough to give developers enough time to complete a meaningful amount of work. But it shouldn’t be too long that the business starts to wonder when they will see the next release. I have seen two weeks sprints work out well for most companies.
This is a list of all the things that need to be developed. During the sprint planning meeting the engineering team looks at the product backlog. Items are moved from the product backlog to the sprint backlog until the team reaches its capacity.m
Learn more about Product Backlog here
During the sprint planning meeting the engineering team identifies items they can complete in the sprint given their sprint velocity. These item together form the sprint backlog. You should not increase the scope of a sprint after it starts. But you can reduce it if in the course of development you find unknowns that the team had not planned for. When this happens you should talk to the product owner and decide on the best course of action.
The sprint planning meeting takes place a day before the beginning of a new sprint. The goal of this meeting is to go over the product backlog, come up with a rough estimate(points) for items and add them to the sprint backlog. This is an interactive session between the developers, product owner and scrum master. Any doubts raised should be clarified in this meeting or added as an action item to be followed up and resolved later. I have often noticed teams suffer from “planning fatigue”. As a result not much attention is paid to requirements at this stage. This causes issues later on during development.
Daily Scrum Standup
Everyday the scrum team meets for not more than 15 minutes. The meeting is held at the same time and place each day. The goal is to get a quick update from each member. Everyone answers the following three questions:
“Parking lot” is a term used during scrum meetings. It is used when an issue is taking too much time and needs to be discussed separately. It means that you park your issue till the end of the meeting. Once the meeting ends the right set of people can get together to solve the issue.
At the end of the Scrum a review meeting is held. The goal of the review meeting is to go over the sprint and close things that have been completed and confirm to the “definition of done”. It is an opportunity for the team to look at what was accomplished and what was changed during the sprint. This provides them insights on how the sprint can be planned better in the future.
This meeting takes place after the completion of the sprint when the sprint review meeting is complete. The goal of this meeting is to look back at the sprint and discuss ways to improve. The following three questions are very effective in running the retrospective.
The retrospective is an opportunity for everyone to share their unique experience. Sometimes people might feel shy to share their opinion in a public forum. Retrospectives can sometimes become repetitive or people might start getting bored. So you might need to spice things up and make it interesting to keep everyone engaged. One fun way to do it is add a fourth section to the above questions. It’s called “shoutouts”. It’s an opportunity to thank your teammates who supported and helped you with something during the sprint. This exercise is a great morale booster for the team. I have used Trello boards in the past to run retro meetings and the stickers in them can definitely add a zing to the meeting.
There are lot of softwares out there but Jira is used widely by scrum teams for creating, managing and running sprints. The reasson why it is so popular is because it is easy to use and there is a strong support mechanism in place if you get stuck.
Scrum provides a lot of benefits to teams that invest in it. Let’s look at some of them.
Everyone in the team is aware of what is in the development queue. They know what is expected from them at the end of the sprint. The product owner keeps all the stakeholders in the loop on what to expect at the end of each sprint. As a result there is no ambiguity on how much progress is being made towards the achievement of product goals.
Scrum is designed to work in the real world. It takes into account:
Scrum focuses on incremental improvements to meet product goals. This means that you don’t invest too much development effort at one go. You can change priorities as they come into focus. Scrum also lets you customize its processes to suit your needs. For example- length of sprint, time allocated to daily standup and the size of your Scrum team can all change.
One of the big challenges with development is that we sometimes tend to forget what we discussed. That causes confusion. Scrum makes sure that everyone is clear on what “DONE” means. It’s agreed upto during the sprint planning meeting and used during the sprint review meetings before closing tickets.
It also give clarity to the stakeholders on what to expect. If they disagree with what’s in the upcoming sprints they can go and talk to the product owner on how things are prioritized.
Scrum encourages efficient working. Documentation is one example of it. In Scrum you only document what’s necessary and needed. You document decisions, milestones and actionable items that need to be tracked.
No process or framework is perfect. While Scrum addresses issues faced by users with older frameworks it creates some of its own.
Off late the debate between “Scrum Or Kanban” has started to heat up. Well you can pick up the one that works better for you. To be successful, just make sure that everyone in the team has been trained in the framework you select. Only when we equip our team with the right tools can they be successful in delivering their goals.