🧭 How We Work (Agile Methodology)
This document is written for anyone, whether you know about technology or not. Here we explain, in plain words, how the zymDev team organizes its work, what words like sprint, daily or refinement mean, and how changes travel from the moment they're requested until they reach the software you use every day.
🌱 What does "working in an agile way" mean?
Imagine that instead of promising "I'll deliver the whole finished system in 6 months," the team says: "every 2 weeks I'll show you a working improvement." That's working in an agile way.
Instead of trying to guess everything from the start, the team:
- Works in short, fixed time blocks (usually 2 weeks).
- Shows real, working progress, not just promises.
- Constantly adjusts course based on what is learned along the way.
This allows the team to react quickly to mistakes, changing priorities, or new needs, instead of waiting months to discover that something wasn't what was actually needed.
📅 The Sprint: our "work block"
A Sprint is simply a fixed period of time (at zymDev, 2 weeks) during which the team commits to making progress on a set of tasks.
Think of the Sprint as a restaurant's cooking cycle: every so often, a new dish comes out to the table. The team doesn't wait to have the whole menu perfect before serving something; it serves what is already ready and well tested.
- Week 1: New features are built and tested.
- Week 2 (Stabilization): No new things are added anymore, only bugs found are fixed, to make sure everything is stable before releasing.
- The following Monday: The new version is released to all users.
📖 If you want to see the technical detail of dates and versions, check the zymDev Core Framework section.
🗣️ The team's events, explained without jargon
The agile framework (technically known as Scrum) relies on a few short, focused meetings. Here's what each one means:
☀️ Daily (Daily Standup)
A maximum 15-minute meeting, held every day, where each team member shares three very simple things:
- What did I do yesterday?
- What am I going to do today?
- Is there any obstacle slowing me down?
It's like the team's daily "weather report": quick, brief, and useful for catching problems early — not for solving them on the spot.
🧹 Refinement
A meeting where the team reviews and clarifies tasks that haven't started yet, before they enter a Sprint. It's like "prepping the ingredients before cooking": it makes sure everyone understands what needs to be done, how big the task is, and whether any information is missing.
Without this step, the team could start working on something poorly explained and waste time correcting course halfway through.
🔍 Review (Sprint Review)
At the end of each Sprint, the team shows what it built and what actually works, in order to get feedback. It's like a showcase or a tasting: the real progress is presented (not slides or promises), and feedback is gathered to keep improving the product.
🪞 Retrospective
An internal team meeting, held after the Review, where the team asks: what went well? what didn't? and what will we improve for the next Sprint? It's the moment to "learn from what just happened" in order to work better next time.
📌 Planning (Sprint Planning)
At the start of each Sprint, the team decides which already-refined tasks will be worked on over the next 2 weeks, based on priority and importance for the business and its users.
🗂️ What is an "Issue" and what types exist?
An Issue is simply a card or record where anything the team needs to address gets written down: it can be a bug, a new idea, a question, or a specific task. All of the team's work goes through one of these "tickets," so there's always a clear record of what was requested, who requested it, and what was done about it.
There are different types of Issue, depending on how big the work is and what it's about:
| Type | In simple words | Everyday example |
|---|---|---|
| 🐞 Bug | Something that isn't working as it should. An unexpected behavior or an error. | "The save button doesn't respond when clicked." |
| ✨ Feature | An idea, request, or new capability that doesn't exist in the system yet. | "I'd like to be able to export the report as a PDF." |
| ✅ Task | A specific, concrete piece of work, that's neither a bug nor a large new feature (e.g., a configuration change, a minor adjustment). | "Update the text of a message shown on screen." |
| 🏔️ Epic | A piece of work so large that it doesn't fit in a single Sprint. It gets broken down into several smaller tasks or stories. | "Redesign the entire billing module." |
| 📖 User Story | Describes something a user will be able to do with the product, told from their point of view. | "As a user, I want to receive a notification when my request is approved." |
| 🚧 Impediment | An obstacle that prevents the team from moving forward (for example, lack of access to a system, or an external dependency). | "We can't continue because we're missing the server access key." |
| 🧪 Test Case | The detailed steps followed to verify that something works correctly before it's released. | "Verify that entering an invalid email shows an error message." |
| 🔬 Spike | An experimental investigation, not meant to build the final product, but to resolve a technical question before committing to a solution. | "Investigate whether it's feasible to connect the system to a new payment gateway." |
| 🗓️ Meeting | Used to register and track the team's meetings and ceremonies (Daily, Review, Retrospective, etc.); it doesn't represent development work. | "Sprint 24 Retrospective." |
💡 In short: if something is broken, it's a Bug. If something doesn't exist yet and is being requested, it's a Feature. If it's a specific piece of work that doesn't fit either of those, it's a Task. And if the work is too large for a single batch, it's organized as an Epic.
🌳 How do changes travel until they reach you? (Branches and Versions)
This is where many people get lost with the "technical" part, so let's explain it as a timeline.
Think of the system's code as a history book that keeps being written. Each "branch" is a parallel timeline, where new things are tried out without risking the main story.
- 🏛️
main(Production): This is the official history, the one every user sees and uses day to day. Only changes that have gone through the full stabilization process arrive here. - 🍲
develop: This is like the restaurant's kitchen. Here, all the changes that will be part of the next version are being "cooked" and combined. - 🌿 Working branches (one per Issue): Every time someone is going to resolve an
Issue(a Bug, a Feature, a Task, etc.), a new, isolated timeline is created, dedicated solely to solving that specific problem. That way, while work happens there, nobody else's work is affected. - 📦
release/vX.Y.Z: This is the "plating tray" before the dish goes out to the dining room. Oncedevelopalready has everything planned for the next version, this branch is created to focus exclusively on stabilizing and testing (the "stabilization week" mentioned above).developnever goes straight intomain: it always goes through this release branch first.
When work on an Issue branch is finished and confirmed to work correctly (through testing and a teammate's review), those changes are merged back into develop, joining the rest of the progress being cooked for the next version.
When it's time to publish, develop is never taken directly: a release/vX.Y.Z branch is created from develop, and that's where the stabilization week happens (only bug fixes are accepted, no new features). Once that release branch is stable:
- A Pull Request from the release branch into
mainis opened and merged, and officially tagged as the new version (e.g.,v6.1.0). - Automatically, a second Pull Request is opened, this time from
mainintodevelop, to sync that version's changes and fixes back into the kitchen. This step is mandatory: if a fix made only during stabilization never makes it back intodevelop, that fix would be lost and the bug could reappear in the next version.
📊 Visual example of the timeline
In summary, the journey of a change is:
- 🗂️ Someone reports or proposes an Issue (Bug, Feature, Task, etc.).
- 🌿 A dedicated timeline (branch) is created just to resolve that Issue.
- 🧪 The work is done, tested, and reviewed to make sure it works correctly.
- 🍲 Once confirmed, it's merged into
develop, joining the rest of the Sprint's changes. - 📦 Once everything planned for the version is in, a
release/vX.Y.Zbranch is created fromdevelop. This step is never skipped:developdoes not go straight intomain. - ❄️ During the stabilization week, bugs are only fixed on the release branch, never by adding new features.
- 🏛️ Once the release branch is stable, a Pull Request into
mainis opened and merged, becoming the new official version every user receives, and tagged with the version number (e.g.,v6.1.0). - 🔁 Automatically, a second Pull Request is opened from
mainintodevelop, to sync every fix from that version back, so nothing made during stabilization gets lost.