Working with Scrum

4.1 What is Scrum?

You've got the gist that everything related to development is standardized. But what if I told you that literally everything is standardized? And this isn't just about variable and function names, though they're standardized too 🤦‍♂️.

There's a development methodology called Agile, and a popular implementation of it is Scrum. Scrum is also referred to as a framework—it sets out all team processes. When meetings should happen, who should attend, what should be discussed, what the meeting outcomes should be, and how they should be recorded.

"But why so much standardization," you ask. Well, first of all, you're working in the high-tech sector—all that high-tech jazz. Second, it's just easier to work with each other this way. And third, pay attention to the last word in your job title Python Fullstack Software Engineer—engineer. And you'll get where this is all coming from.

4.2 What working with Scrum looks like

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

Scrum divides projects into development cycles called sprints, which usually last from one to four weeks. Each sprint kicks off with task planning and wraps up with a presentation where the team shows off the results achieved.

The key elements of Scrum include roles, events, and artifacts.

Main roles include the Product Owner, who defines the product requirements, the Scrum Master, who supports the process according to Scrum rules, and the development team, who do the actual work.

Main events include daily meetings (daily meetings or standups), sprint planning, retrospectives, and demonstrations of the work results. Artifacts include the product backlog, sprint backlog, and product increment.

Don't freak out! Even though having everything regulated might seem a bit scary, working "with Scrum" is easy and enjoyable. Scrum resolved the main conflict between developers and customers/product owners.

Developers always wanted to be left alone to do their work. Meanwhile, product owners needed to urgently add new features, change something, or run some experiment.

Scrum broke down development into stable periods—sprints (usually 2 weeks). During one period, developers do only the tasks that were planned for the current sprint. If the customer needs something done urgently, these features are added to the next sprint.

4.3 Sprint & Scrum Board

Sprint is the main development cycle in Scrum, lasting from one to four weeks. As we've mentioned, during this period, the team works on completing a specific set of tasks from the product backlog.

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

Throughout the current sprint, developers and the product owner should meet and discuss tasks for the next sprint.

Backlog is a list of all tasks that need to be done. In Scrum, there's a product backlog, which includes all product requirements (features), and a sprint backlog, which consists of tasks chosen for implementation in the current sprint. The backlog is a living document, 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 task board with statuses. The board is divided into columns, which usually represent task completion stages, like "To Do," "In Progress," "Under Review," and "Done." This lets the whole team see progress and easily spot any process bottlenecks.