Working with Scrum

13.1 What is Scrum?

You've already figured out that everything related to development is standardized. But what if I tell you that literally everything is standardized? And I'm not even talking about variable and function names, although they are standardized too 🤦

There's this development methodology called Agile, and its popular implementation — Scrum. Scrum is also known as a team framework: it defines all the processes within the team. When meetings should happen, who should be there, what should be discussed, what the meeting outcomes should be, and how they should be documented.

But why so much standardization, you ask. Well, first off, you're working in a high-tech sector — all that high-tech jazz. Secondly, it makes it easier for everyone to work together. And thirdly, in your job title Frontend Fullstack Software Engineer, pay attention to the last word — engineer. And you'll see where it all comes from.

13.2 How Work Looks Like with Scrum

Scrum is an agile project management methodology often used in software development. It's based on iterative and incremental processes.

Scrum splits projects into development cycles called sprints, which typically last from one to four weeks. Each sprint kicks off with task planning that needs to be done and wraps up with a presentation where the team showcases what they've achieved.

Key elements of Scrum include roles, events, and artifacts.

Key roles are the Product Owner, who defines product requirements, the Scrum Master, who supports the process in accordance with Scrum rules, and the development team, who actually do the work.

Key events include daily stand-up meetings, sprint planning sessions, retrospectives, and demos. Artifacts include the product backlog, sprint backlog, and product increment.

Don't freak out: even though regulating everything seems a bit intimidating, working with Scrum is easy and enjoyable. Scrum solved the main conflict between developers and clients/product owners.

Developers always asked to be left alone and allowed to work peacefully. But product owners needed to urgently introduce new features, add stuff, or run some kind of experiment.

Scrum broke development into stable periods — sprints (usually 2 weeks). During this time, developers only work on tasks planned for the current sprint. If a client needs something done urgently, they add these features to the next sprint.

13.3 Sprint & Scrum Board

A Sprint is the main development cycle in Scrum, usually lasting from one to four weeks, during which the team works on completing a specific set of tasks from the product backlog.

At the start of each sprint, there's a planning session where the team picks tasks from the product backlog and commits to completing them. The sprint ends with a demo of completed work and a retrospective where the team analyzes the process over the sprint and looks for ways to improve the next sprint. This approach allows for regular product updates, quickly responding to changes in requirements and priorities.

During the current sprint, developers and the product owner should meet to discuss tasks for the next sprint. The list of tasks is called the backlog.

The Backlog is a list of all tasks that need to be completed. In Scrum, there's the product backlog, which includes all product requirements (features), and the sprint backlog, which consists of tasks selected for implementation in the current sprint. The backlog is a living document that is regularly updated and revised to ensure alignment with current business goals and market conditions.

The current sprint backlog is often displayed as a Scrum Board — a kind of board with tasks and statuses. The board is divided into columns that typically represent stages of task completion, such as "To Do," "In Progress," "Under Review," and "Done." This allows the entire team to see progress and easily identify any bottlenecks in the work process.