Working with Scrum

1. What is Scrum?

You’ve already seen that everything related to development is standardized. What if I told you that practically everything is standardized? And we’re not even talking about variable and function names—those are standardized too 🤦‍♂️.

There is a development methodology called Agile, and its popular implementation is Scrum. Scrum is also called a framework—it defines all the processes in the team: when meetings should happen, who should attend, what should be discussed, what the meeting outcomes should be, and how they must be documented 📋.

“But why so much standardization?” you may ask. First, you work in a high-tech sector—high tech and all that. Second, it makes working with each other simpler. Third, in your job title .NET Software Engineer, pay attention to the last word—engineer—and you’ll see where this all comes from.

2. What working with Scrum looks like

Scrum is a flexible project management methodology often used in software development, based on iterative and incremental processes 🔁

Scrum breaks projects into development cycles/stages called sprints, which typically last from two to four weeks. Each sprint starts with planning the tasks to be completed and ends with a review where the team demonstrates the results achieved 🎯.

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

• Core roles are the Product Owner, who defines product requirements; the Scrum Master, who supports the process according to Scrum rules; and the development team, who do the work.
• Core events are daily meetings (daily stand-ups), sprint planning, retrospectives, and demos.
• Artifacts include the backlog (task list) of the product, the sprint backlog, and the product increment 📋.

Don’t be scared! Although regulating everything may look a bit intimidating, working “the Scrum way” is easy and pleasant. Scrum resolved the core conflict between developers and customers/product owners 🤗

Developers have always asked to be left alone so they can focus on the work. Product owners, on the other hand, often need to urgently add new features, change something, or run an experiment 🧪.

Scrum splits development into stable periods—sprints (usually 2 weeks). During a period, developers work only on the tasks planned for the current sprint. If the customer needs something done urgently, they add those features to the next sprint 🗓️.

3. Sprint & Scrum Board

Sprint is the primary development cycle in Scrum, lasting from one to four weeks. As mentioned, during this period the team works on a specific set of items from the product backlog.

At the start of each sprint, there is a planning session ⏳ where the team selects items from the product backlog and commits to delivering them. A sprint ends with a demo of the completed work and a retrospective, where the team analyzes the sprint process and looks for ways to improve the next one. This approach enables regular product updates and quick responses to changes in requirements and priorities.

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

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

The current sprint’s backlog is often visualized as a Scrum Board ✅—a board with tasks and statuses. The board is split into columns that typically represent stages of work, such as “To do”, “In progress”, “In review”, and “Done”. This allows the whole team to see progress and easily identify any bottlenecks in the workflow.