Ways of Working
At ZAMO, we believe that the right methodology is the foundation of successful project delivery. Our proven ways of working combine industry best practices with our years of experience to ensure consistent, high-quality results for every client.
Our core principle is to understand the business, deliver what matters to customers by collaboration, alignment with the best quality.
High Level Flow
Our development process follows a structured approach that ensures quality delivery while maintaining flexibility for changing requirements.
| Stage | Description | Key Activities | Definition of Done |
|---|---|---|---|
Product Backlog | Main bucket of product requirements | PO: Feeds issues into the backlog | Issues are created in JIRA |
Release Backlog | A prioritized bucket for the next release | PO: Provides business rules and process flows | Issues are moved to the next Sprint's "To Do" list |
Analysis & Design | Tickets are groomed and prepared for the next sprint | PO: Provides UI/UX design Tech Leads: Work on technical design Scrum Master: Conducts grooming sessions | Issues are moved through "IN ANALYSIS", "IN DESIGN", "IN DRAFT TECH DESIGN", and finally to "READY FOR DEV" |
Sprint Backlog | The bucket of work for the current sprint | PO: Confirms readiness and design Tech Leads: Handle preparation and resource allocation Scrum Master: Conducts Sprint Planning | PO confirmed; Design is ready and approved by PO |
In Development | Ticket is being actively implemented | Developers: Write test notes, code, perform unit/integration tests, open Merge Requests Tech Leads: Monitor progress Scrum Master: Conducts daily standups | Code is peer-reviewed and merged to the dev branch. Unit test coverage is >= 65% |
In Review | The ticket is ready for review | PO: Verifies screenshots and business expectations Developers/Tech Leads: Conduct code reviews QA: Cross-check from another developer | Test Cases & Scenarios are reviewed. All acceptance criteria are met. No Major or higher bugs |
Done | Ticket is ready for release | QA: Confirms all test cases have passed Scrum Master: Conducts Sprint Review and Retrospective | Ready to deploy to Production |
How It Works
Our structured approach to project delivery
- Continuously revise the high-level roadmap
- Set release milestones based on the roadmap
- Run 2-week sprints
The sprint focus should be aligned with the next release milestone for both:
- Building the current features
- Analysis & Design for the next sprint (Sprint + 1)
Sprint Ceremonies for Software Team
Our structured 2-week sprint ceremonies ensure effective communication, planning, and continuous improvement.
Monday
- 9:30 AM - 10:00 AM: Demo Trust (30')
- 10:00 AM - 11:00 AM: Sprint Review & Retro (1h)
- 11:00 AM - 12:00 PM: Sprint Planning #1 (1h)
- 2:00 PM - 3:00 PM: Sprint Planning #2 (1h)
Tuesday - Friday
- 9:00 AM - 9:15 AM: Daily Standup (15')
Wednesday
- 10:00 AM - 11:00 AM: Story Grooming (1h)
Monday - Friday
- 9:00 AM - 9:15 AM: Daily Standup (15')
Wednesday
- 10:00 AM - 11:00 AM: Story Grooming (1h)
Friday
- 9:15 AM - 11:00 AM: Sprint Review (1h 45')
- 11:00 AM - 12:00 PM: Sprint Retro (1h)
Sprint Lifecycle
Understanding the beginning and end of our sprints
Sprint Planning
Go through and agree on the goals & objectives of the next sprint for both business and development. Set the delivery commitment for the team.
Team Capacity Estimation
This is usually based on the velocity of the team. We can estimate the first time and adjust over time. E.g., a dev who can deliver 3 points/day has a sprint capacity of 1 dev * 3 points * 9 days = 27 points.
Story Sizing
User story points reflect complexity, uncertainty, and effort. Use the Fibonacci series for relative estimation (1, 2, 3, 5, 8, 13...). We take user stories into the sprint based on the team's capacity.
Sprint Review
- Review the burndown chart
- Review the commitment (what was delivered vs. what was not, and why)
- Discuss achievements
- Review the release status (optional)
Retrospective
The purpose is to identify continuous improvement items by asking:
- What have we done well? (Keep doing)
- What was not good? (Stop doing, identify actions to improve)
- What have we learned?
- Praise / awards
Vote for the top 3-5 items to identify actions for the next sprint.
Keep monitoring & review these items in the next retrospective
Releases
Our approach to software releases
We need to love our own software before customers do.
Be like a customer and explore the products from different scenarios.
Track any issues found and decide if they need to be fixed.
The formal release of the software with proper deployment and monitoring.
Ready to Experience Our Proven Ways of Working?
Let's discuss your project requirements and determine the best methodology approach for your success.