Join the Scrum

When a development team starts building a web application, what is the first thing they do? Start writing code? Not quite. So how does a typical development team actually work, and what rituals help them deliver high-quality software in record time?

Most development teams operate using some form of Agile methodology. One of the most common frameworks in the industry is Scrum. By adhering to Scrum, a team delivers software incrementally. This gives stakeholders the flexibility to review each increment periodically and make adjustments as needed.

An increment is a working, production-ready piece of software.

Before going further, I want to manage your expectations. What I am about to describe is my own interpretation, based on what has worked best for the teams I have been part of. Do not quote me to your employers. Instead, use this article to understand the concepts and how they fit together. Every team works slightly differently, and each should adapt their workflows to leverage the strengths of its members.

For the full details, read the Scrum Guide. What follows is my own brief overview for a working understanding.

What is Scrum?

A Scrum team consists of up to 10 people:

The Product Owner owns the product backlog — a prioritized to-do list — and makes executive product decisions based on client and business needs.

The Scrum Master facilitates, advocates for, and coaches the team to ensure Scrum rules are followed and that the team works at a sustainable pace.

The Development Team a self-organized team, consisting of many cross-functional members responsible for the development of the product. It is important to note that the development team does not only contain software engineers, but whoever is needed to complete the task at hand. Although this means that members can easily come and go, it is important to consider the loss in working velocity when onboarding a new member, or when losing someone with experience.

Some of the more common roles that you may see in a Development Team includes:

Each team member has a slightly different role, and do not be surprised if someone wears several hats. A team also does not need to include every role listed above. If you want to dive deeper into any of these roles and the skills they require, I recommend roadmap.sh — an excellent resource maintained by the open source community.

Scaling Up

You may be wondering: if a Scrum team is capped at 10 people, how are tech companies so large? The answer is Scaled Scrum — frameworks such as Nexus, LeSS, or SAFe coordinate many Scrum teams. A Product Owner and Scrum Master can oversee one or several teams. Using Airbnb and its hosting, experience, and online experience products as an example, Scaled Scrum would split the work by product line:

As Airbnb grows further, they may split these teams into smaller teams, each with a Product Owner managing a specific service. The following is an example of the services within the Traveler Product that each Scrum team might work on:

Scrum Rituals

A Scrum team produces a working increment over a period of 1-4 weeks, known as a Sprint. Sprint length is usually kept consistent to establish rhythm and a predictable release cadence. The core Sprint rituals:

E.g. A 4-week sprint should have a maximum of 2 × 4 = 8 hours of Sprint Planning.

Sprint Planning happens before the sprint begins. The team re-prioritizes the Product Backlog and selects items for the Sprint Goal they commit to completing. The development team also drafts a plan for how to achieve that goal.

The Daily Scrum is a short standup to monitor progress and surface blockers. Each person answers three questions:

The Sprint Review is where the increment is showcased to stakeholders. Stakeholders inspect the work, raise questions or concerns, and suggest adjustments.

The Sprint Retrospective is a reflection on how the team worked during the sprint. Three questions:

Additional Rituals

Some companies add extra rituals to help the team maintain a stable velocity. These include:

A Mid-Sprint Review (also called a Sprint Checkpoint) is usually held halfway through the sprint. It checks whether there is a risk of missing the sprint goal and, if so, allows the team to make adjustments.

A Tech Bounce (also called a Design Review or Technical Planning) may be useful if the development team is mixed with non-technical members. This session is carved out of Sprint Planning to align on technical specifications such as database design, API request and response shapes, and frontend/backend validations. The goal is to get engineers on the same page so that frontend and backend work can proceed concurrently. Those not involved in the Tech Bounce run their own variants — for example, designers and UX researchers align on discovery tasks and hypotheses, while QA plans out their automation testing strategy.

A Tech Spike (a term from Extreme Programming) may be done before the Tech Bounce to make sure the technical design for the current or next sprint is efficient and scalable. Examples include database design work, performance optimization, and vulnerability research.

AI and Scrum

AI is reshaping how software teams operate, from the roles people play to the tools they use and the products they ship.

AI's Impact on Dev Team Roles

AI coding assistants like GitHub Copilot and Cursor have shifted what developers spend their time on. Writing boilerplate, debugging common errors, and querying APIs are now partially handled by AI. Developers increasingly focus on system design, architecture decisions, and reviewing AI-generated code.

For me, documentation is fully handled by my ZeroClaw agent. A few days ago, an AWS representative asked how I start my day. My answer seemed to stun them, I begin my day by reviewing merge requests from my agents that worked throughout the night.

Quality Assurance engineers have seen the biggest disruption from AI powered tools. Ironically, when the AI boom started, some companies cut their QA teams. I suspect those companies are now regretting that decision. With software shipping faster than ever, QA became the guardian preventing AI slop from reaching production.

While AI powered tools can generate test cases, automate regression testing, and detect anomalies in production, QA engineers are evolving into test strategists, deciding what to test and when, while AI handles the how. On the how I still believe in code. AI can control a mouse and use screenshots to identify what to click, but writing code to do the same thing is far more cost effective than LLMs interpreting screenshots and moving a cursor.

With the help of AI, a two person team can now ship products that previously required ten people. AI fills gaps in frontend, backend, DevOps, and even light data work. I believe the leverage is asymmetric, smaller teams gain more from AI than large, well-resourced ones. My reasoning is that smaller teams need less coordination. Splitting frontend and backend across two engineers eventually requires integration work. It makes more sense for one developer to build an entire feature so that the planning of the frontend and backend application is cohesive. If it was split amongst two engineers there is a risk that different people may have built two systems that do not integrate well with each other, slowing the process down.

AI Tools in Scrum Rituals

Scrum rituals are getting AI assistance too. Tools like Geekbot run asynchronous standups, compiling answers into a digest without requiring everyone online at the same time. Sprint planning gains AI-assisted backlog refinement, surfacing dependencies, estimating effort, and flagging ambiguous user stories.

Retrospectives get AI analysis. Tools like Parabol use AI to cluster feedback, identify recurring themes, and suggest action items from open-ended team comments.

Sprint reviews benefit from AI-generated release notes. Instead of manually documenting what shipped, AI diffs the increment against the previous version and drafts the summary.

These tools do not replace human judgment, they reduce administrative overhead so the team spends more time on delivering work. After all, most of he time, management requires a write up on progress updates on where the product is going. Having these AI tool automate some of the processes gives everybody in the scrum team more time to make an impact than doing mundane paperwork.

In my previous company Glints, I managed to implement a workflow using Lark Anycross to sync Gitlab, Lark and Jira together. For example, opening a branch will move the Jira card to implementing, assigning a reviewer in Gitlab will move the Jira card to review and send a message to the reviewer with the necessary links such as Jira Card, merge request and the review application.

Building AI-Powered Products

Building AI-powered products is challenging. Evaluation speed and update frequency are constant concerns. Every model behaves differently, the same system prompt that yields 95% accuracy on GPT-3 may produce worse results on GPT-4. Upgrading to a newer model does not guarantee improvement. Therefore it is very important to have automated testing, this ensures that your tests are replicable so that when newer models ship, you can run evaluations and make necessary tweaks quickly.

A new model launch also disrupts product workflow. Since nobody knows exactly when a model will release, the traditional backlog-driven approach often fails. Users expect new models like Opus 4.6 to appear in their application within days of launch if not hours. Missing a major release window risks losing users to competitors. To ensure product competitiveness, teams will sometimes need to break the traditional development cycle, and management needs to understand that timelines will need to be prolonged when new model integrations land unexpectedly.

Conclusion

Scrum is not a perfect framework, it is one of many tools available to teams. Its strength lies in structure and predictability, making it ideal for teams that need clear accountability, regular stakeholder checkpoints, and measurable sprint outcomes. However, structure can become bureaucracy if the team does not actively reflect and adapt.

In my experience, Scrum rituals are far more effective when working remotely. In a remote setup, everyone works at their own pace, these rituals create shared checkpoints for the team to sync up. In a physical workplace where teammates sit side by side and talk constantly, rituals like the Daily Scrum can lose their value.

While Scrum is one of the most popular delivery frameworks, other agile methods exist, Kanban for continuous flow, Extreme Programming for engineering practices, and Lean for waste reduction. Shape Up from Basecamp takes a different angle entirely: 6-week "bake" cycles with fixed capacity, appetite-based scope-setting, and hill charts instead of burndown tracking. It works well for teams that want forward momentum without the overhead of sprint planning.

Beyond agile, some companies skip it entirely and favour the waterfall method for projects with rigid requirements and compliance needs.

Ultimately, the best framework is the one your team will actually follow. Pick one, run with it, and course correct as you learn what works for your context.