Agile Rituals

Hey DevLearners,

As promised, I’m back with another deep dive into Agile. This time, we’ll explore Agile Rituals, covering the core meetings and best practices that keep teams productive.

If you’re new to Agile and wondering why it's important, I recommend checking out my previous post before diving in.

Agile vs Waterfall: Why Agile is the Future of Software Development

Agile is more than just a buzzword—it’s a game-changing way to build software. Learn how Agile improves upon the Waterfall model, why customer feedback is crucial, and how incremental improvements lead to better products.

The Dev LearningsThe Dev Learnings Team

Now, let’s get straight to it!

Some Useful Terminologies

JIRA

JIRA, developed by Atlassian, is a widely used tool for managing projects in Agile teams. For the sake of brevity, I'll assume you're using JIRA, but the same principles apply to other tools.

Sprint

Remember the Agile cycle diagram? The one that starts with design, moves through development, testing, and then repeats? A Sprint is a single iteration of that cycle.
Most teams find that a two-week Sprint works best, but you can experiment with different lengths based on your team's goals.

Sprint Backlog

The Sprint Backlog is a list of tasks and user stories that will be taken up in the upcoming Sprints. The Product Manager (PM) usually creates these tickets for new features, but developers and QA engineers can also contribute.

Ticket

A ticket (or JIRA ticket) represents a single task, feature request, bug fix, or Proof of Concept (PoC). Each ticket should clearly define what needs to be done and include relevant details.

Definition of Done

For feature-related tickets (not bugs), the Definition of Done outlines the criteria that must be met for a ticket to be considered complete. If anything is missing, the feature isn’t truly done.

Scrum Master

The Scrum Master manages the Agile process within a team. This role can be filled by someone not directly involved in development, but often it's a senior team member.

Story Points

Each ticket is estimated in Story Points during Sprint Planning. These points reflect the complexity of a task rather than the actual hours required to complete it.

Velocity

Velocity measures the total Story Points completed by the team in a Sprint. When a ticket meets the Definition of Done, its Story Points contribute to the team's Velocity, helping gauge overall progress.

Agile Meetings You’ll Encounter

If you thought Agile meant no meetings and uninterrupted coding time, think again! Meetings (when done right) are crucial to keeping teams aligned and productive.

However, if you’re unsure whether a meeting is worth attending, I’ve written another guide on how to decide if a meeting is necessary.

Not Every Meeting Needs You – Take Back Your Time

Tired of endless meetings killing your productivity? Learn how to decide which meetings truly need you, when to say no, and how to reclaim your time for meaningful work.

The Dev LearningsThe Dev Learnings Team

Here are some key Agile meetings you’ll encounter:

Daily/Standup

This is the shortest meeting, typically held in the morning before work begins. Each team member shares:

• What they worked on yesterday
• What they plan to do today
• Any blockers they’re facing

Why it’s important:

• If a teammate is unexpectedly out sick, the team already knows what they were working on.
• It’s a great way to ask for help early instead of getting stuck for hours.

Keep it short—10 to 15 minutes max. If discussions run long, schedule a follow-up.

Sprint Planning

Held before a new Sprint starts, this meeting defines the work for the next 2-3 weeks (or your chosen Sprint length).

If your team has a Product Manager (PM), they’ll present feature requests and bug fixes. Developers discuss and clarify requirements before committing to work.

If you’re working on a technical product, you might propose your own tasks—fixes, optimizations, or refactors.

Sprint Retrospective

Every Sprint ends with a Retrospective, where the team reflects on:

✅ What went well (e.g., successfully adopting a new technology)
❌ What didn’t go well (e.g., delays due to dependencies on another team)

No one should feel judged—this is about improving the process, not blaming individuals. At the end of the meeting:

• Action items are listed.
• Someone is assigned to follow up.
• In the next Retrospective, the team reviews what happened with those action items.

That’s a wrap for today’s Agile deep dive! There’s more to Agile than just meetings, and I’ll cover how to thrive in an Agile environment in an upcoming post.

What’s your experience with Agile meetings? Love them or hate them? Let’s discuss!