Getting Started with Scrum in an Agile Way

Scrum is an agile way to manage any project. It is one of the frameworks of Agile practices. It can be used interchangeably in civil, aviation, construction, HR, marketing, finance and law. However, we use Scrum methods in the software development industry more often than in other industries due to the high level of complexity, requirements and product fit with the rapidly changing market.

Scrum Teams

There are no fixed rules about the number of team members. The standard practices recommend from 4 and up to 10 members in any single team of any department. Any less or more than the recommended number would not be feasible, as advised by the Scrum books.

The Agile way is an umbrella term for a Software Development Life Cycle. It is a methodology to adapt to frequent changes in a project within a timeboxed work progress.

Agile focuses on each member of a team. In essence, there are two types of teams in an Agile way. Teams could be either self-managed or cross-functional.

Self-managed Teams

• They don't depend on any external member role, tool or tech.
• Each member of the team is self-sufficient in their responsibilities.
• Less to no constant supervision is required in this kind of team setup.

Cross-functional Teams

• Members have a blending role. A member could have multiple roles depending on the context of the workflow.
• Each team member can perform all kinds of cross-functional work related to the project.
• In case of any absence, another member should be quickly ready to handle the remaining work with similar expertise expected of the absentee. Hence everyone is equally skilled at every other task.
• These kind of teams are hard to form and requires better communication.

Pillars of Scrum

Scrum is an empirical process of learning from past experiences. It tries to address the most complex problems within the project's architecture.

There are three major pillars of Scrum.

1. Transparency: The pillar imposes a clean and clear understanding of the overall work progress among all the team members. Everyone in the team should be aware of the work log.
2. Inspection: It imposes a frequent check and validation of rapid changes in the project.
3. Adaptation: It emphasises modifying and working in sync with the previous changes.

Scrum Events

The following are the different rituals of Scrum.

1. Sprint Planning

Sprint Planning is a physical meeting at the start of the sprint. It is a meeting where only team members join and discuss tasks to plan for an upcoming sprint.

Product Owners, Scrum Masters, Developers, Designers, QA, and everyone assigned the lead role in the project should sit together in a Sprint Planning meeting to discuss and set goals before starting the sprint.

2. Sprint

Sprint is a time-boxed concept of logging a team's work. The time could be boxed from 1 week to 4 weeks at max. Sprints for more than four weeks are not feasible.

The team discusses their daily work logs, dependencies, blockers and frictions in the project during the sprint. And to reduce the friction, the Scrum Master could enact a certain kind of grooming session in between sprints.

3. Daily Scrum/ Standup (approx. 15 mins)

As sprint starts, daily Scrum or standup is timed at around 15 mins depending on what suits the team. Minor individual work updates are not compulsory.

However, an overview of the overall task discussion is necessary. Notetakers/Scribes are assigned to write these meeting notes. Make sure the tasks are on track in the overall project. The sprint meeting date, time, and meeting room should be fixed to prevent hassle and confusion.

These daily standups help team members mitigate the hurdles for an effective and efficient process.

4. Sprint Review (approx. 30 mins)

One of the most important parts of Scrum is Sprint Review. It takes place at the end of the running sprint. It involves team members, QA and product owners to discuss the backlog and team velocity.

Depending on the scrum master, product demos could also be presented in this meeting. However, prioritising user stories is a must step in sprint reviews. The team lead must review whether the incremental updates are completed as expected, tasks have a better QA acceptance rate, and the team has an equal workload divided among all members so that backlog is not skewed to only one department.

5. Sprint Retrospective (approx. 30 mins)

Another complementary part that comes after Sprint Review is Sprint Retrospective. In general, it is a recurring meeting after Sprint Reviews where only team members are involved in discussing what went wrong, what went as expected and what could be done to improve further ahead in the upcoming sprints.

There are circulated misconceptions that Sprint Retrospective is similar to Sprint Review. However, that is a myth. Usually, both last around 30 mins depending on the team, but the major difference is the involvement of people in both meetings. Sprint Review involves Product Owners/Stakeholders, whereas Retrospective has only team members.

6. Product Backlog vs. Sprint Backlog

A product backlog is a big basket of all project features intended to complete in an iteration. It holds all the milestones (epics) and major points included with the expected release.

At the end of the sprints, it could hold archived and postponed features. A sprint backlog is the smaller basket of Product Backlog. It contains all the features handpicked from the Product Backlog at any time.

Imagine you got two baskets, one big and one smaller. You climbed an apple tree and emptied it by picking all the apples. You put all the apples in the big basket and drove home. Now you handpick some ripe apples from the big basket and put them in a small basket on your dining table. After a week of having breakfast, apples will finish, and you need to pick more ripe apples from the big basket again.

The tree is your ideation of a new project. Emptying the tree is requirements analysis. The big basket is your Product Backlog. The small basket is your Sprint Backlog. Each apple is a task. Each week is a Sprint. And you are a Scrum Master picking apples in an Agile way.

Meetings

In any active project, all kinds of physical or virtual meetings should only consume around 10 to 20% of the overall time. Any more time spent than 20% in meetings could be exhaustive, not feasible and less fruitful.

Scrum Masters should be attentive to daily meetings and ensure everyone stays on track, utilises meeting runtime, and doesn't deviate from agendas. In the absence of Scrum Master, a project lead within the team should equally be capable of running the daily meetings without much friction. Scrum Master must be present for sprint meetings is a myth.

Team Velocity

Team velocity measures a team's capability to perform the sprints. It reviews the metric based on story points or time hours. In case of discrepancies, the scrum master could re-adjust the velocity so that the overall performance and motivation are on par.

Estimation

T-shirt sizing is one of the ways to estimate user stories and tasks. Usually, the new teams learning the Agile ways are benefitted from this estimation technique. Categorising tasks into Small (S), Medium (M), Large (L), and Extra Large (XL or XXL) could be implemented by Scrum Masters where the team is new to Agile methods.

Estimating a task is tough. It is one of the hardest skills to learn in Scrum. In most of the Project Management tools used, estimation is done in two ways.

1. Story Points: Using units to estimate complexity, size and effort.
2. Time: Using minutes, hours, and days to estimate effort.

Story Points is a better one to use. However, time is the first approach for new teams.

Task estimation should be done by defining Story Points based on Fibonacci numbers (0, 1, 1, 2, 3, 5, 8, 13…). The primary goal of estimation is to break down tasks into smaller chunks of smaller story points. Trying to indulge in huge story points will deplete your productivity.

Being Agile vs. Doing Agile

Adopting Agile in your project is understanding the core difference between being agile and doing agile. Being agile requires an in-depth understanding of the gist and performing agile practices accordingly, whereas doing agile is doing what you're supposed to do. A balance between both ways reaps fruitful in the proper implementation of Agile methodologies.