Process Management

Why We Use Agile & Scrum

Virgo Development uses Agile and Scrum to keep projects transparent, flexible, and focused on delivering real value quickly. Our process breaks large goals into smaller, manageable pieces that can be designed, built, tested, and reviewed in short cycles. This approach helps our team and clients stay aligned and easily adapt to change as projects evolve.

Agile Development

Agile development is an iterative process — meaning we build and refine software step by step. Each iteration delivers functional improvements that clients can see and respond to. This continuous feedback loop helps ensure we're always building what matters most and adjusting efficiently when priorities shift.

Visualizing Workflow

We use Kanban boards (Trello) to give everyone — team members and clients — a clear view of the project's progress. Every task is tracked visually from start to finish, making it easy to see what's planned, what's in progress, and what's complete. This transparency helps prevent bottlenecks and keeps work moving smoothly.

Limiting Work in Progress (WIP)

By limiting how many tasks are in progress at one time, our team stays focused on finishing work before starting new items. This improves quality, reduces context switching, and ensures a steady, predictable workflow.

Continuous Improvement

After each sprint or project phase, we review what worked well and what could improve. These discussions lead to small process enhancements that build long-term efficiency and innovation across our team.

Scrum for Incremental Delivery

Our projects run in time-boxed sprints. Each sprint focuses on specific goals drawn from the product backlog, ensuring consistent delivery of working software. Frequent Sprint Reviews allow clients to see progress early, provide input, and help guide the next sprint's priorities.

Estimates, Project Management & Stages

The Budgetary Estimate

1. During the Kick-Off Call, we will break the project into clear phases, which will allow for more precise time and cost estimates. These estimates may be updated as needed to maintain full transparency and ensure the client can approve any changes in scope or direction.
2. The budgetary estimate serves as both the scope definition — outlining expected deliverables and target outcomes — and the contractual understanding for billing, hosting, ongoing work, and dispute resolution procedures.
3. When estimates are provided to customers, a 1-hour Kick-Off Meeting is included in the estimate and communicated to the client. The intent is to improve communication, minimize rework, confirm MVP alignment, and avoid non-essential work in the billing process.

Kick-Off Meeting (Required Before Phase 1 / MVP)

Before starting Phase 1 (MVP) of each project, Virgo Development requires a Kick-Off Meeting to ensure all active agents involved with the project are aligned on goals, MVP scope, sprint plan, and review checkpoints. As part of this session, Virgo Development will provide strategic consulting to help the client clarify the most effective path to the MVP.

Required Attendees

• The Project Manager
• The Lead Engineer
• The Design (UI and UX) Lead
• The Customer (and any customer stakeholders needed for approvals)

Kick-Off Meeting Structure (30–60 minutes)

1. Confirm Project Vision (North Star) — Clarify the project's overall goals and vision so everyone understands the client's "North Star." Define success for Phase 1 (MVP) by confirming key users, core workflows, desired outcomes, and any major constraints or non-negotiables.
2. Define the MVP (Aha Moment / Phase 1 Target) — Identify the MVP — the first testable version of the product that shows real value to the client. Outline what is included and excluded from this phase and agree on high-level acceptance criteria for MVP completion.
3. Plan MVP Sprints and Reviews — Break the MVP into sprint-sized deliverables that can be demonstrated and reviewed. Confirm sprint cadence, capacity, the initial prioritized backlog, tentative Sprint Review schedule, and the "Definition of Done" for reviewed items.
4. Manage Change and Minimize Scope Creep — New requests are added to the backlog, not mid-sprint. Each request includes an estimated time and potential impact on budget or timeline. If changes significantly alter the MVP estimate, Virgo Development will pause to provide either a revised estimate or a new phase proposal.

Kick-Off Meeting Outputs (What the Client Receives)

• A written MVP summary (North Star + Aha Moment + acceptance criteria)
• A prioritized MVP backlog (initial scope baseline)
• A proposed sprint plan for MVP
• A Sprint Review approach — what gets approved, how feedback is captured, how changes enter the backlog
• A note of known risks, blockers, or dependencies

Meetings / Sprint Reviews / Standups

Sprint standups are scheduled for 15 minutes and cover three questions:

1. What did I work on in the last sprint? — Demonstration of completed work, feedback collection, identification of improvements.
2. What am I working on in the next sprint? — Backlog prioritization, task assignments, team capacity, definition of "done" for each work item.
3. What issues are blocking me? — Blockers are identified and ownership is assigned.

Kanban Management

Virgo Development utilizes Kanban (Trello), a lean workflow management system focused on continuous value delivery. This approach visualizes work, limits work-in-progress, and optimizes flow to minimize lead times.

• Notes — Project records including meeting notes and project reports (hour summaries and overview documents).
• Backlog — Staged and prioritized tasks before moving to In Progress. Each card includes incremental tasks for feature completion, color coding, user stories, and estimated time.
• Blocked (On Hold) — Progress cannot be made without eliminating the blocker.
• Ready for Development (In Progress) — Illustrates who is working on the task and captures notes and collaboration.
• Ready for Review (Needs Review) — QA Process: Project Lead tests; Client tests and approves.
• Complete / Reviewed — Record of activity; ready for staging.

Project Reports

Project reports create a clear, time-stamped record of what work was completed, when it was done, and how it affected the budget and timeline. If questions or confusion ever arise, this consistent documentation allows everyone to review the step-by-step history of the project.

• Tasks are labeled (engineering, design, project management, etc.) creating a visual representation of where time was spent.
• Scope change tasks are tagged and reflected in the overall budget at the top of the Project Report, illustrating how a scope change impacted the overall targeted budget.

Invoices

• The tasks on invoices align with the tasks referenced on the Project Report and Trello boards.
• We bill on the 1st and the 15th of each month.
• The initial invoice includes payment for the first sprint, or 20 hours, as a commitment deposit. Hours are used accordingly. After the initial invoice, the project switches to hourly billing for actual hours used.

Deployment & Continuous Integration

Deployment and Continuous Integration (CI) are key practices in modern software development that streamline code delivery. Deployment releases new or updated software to staging and production environments, while CI frequently merges code changes from multiple developers into a shared repository.

Staging Environment

A staging environment is a pre-production testing ground that closely mirrors the live environment. It allows developers and QA teams to conduct final tests, identify issues, and validate new features before deployment.

Quality Control Process in Staging

1. Software Publication to Staging — Software is pushed to the staging environment. Related Kanban cards are moved to "Ready for Review" status.
2. Engineer Testing — The responsible engineer conducts thorough testing and quality assurance: functional testing, performance testing, and user experience evaluation.
3. Issue Identification and Resolution — Any issues identified during testing are documented, addressed, and re-tested.
4. Client Review and Approval — The client is notified that the software is ready for their final quality check. The client is responsible for final approval before production release.
5. Production Preparation — Once client approval is received, the software is prepared for production deployment.

Production Environment

The production environment is the final stage where fully tested applications are deployed for end-user access — the live, public-facing version of the software. Pushing a site live involves moving vetted code from staging to production servers, ensuring proper setup of all components.

Post-Production Bugs

Virgo Development defines a bug as:

• A deliverable published to the Production Environment that does not look or behave as specified by the client.
• A deliverable that does not meet quality standards.
• A deliverable that is missing a feature outlined in the Kanban/Agile Process.

When a bug is reported: (1) The client notifies Virgo Development via email. (2) An engineer investigates to determine the cause. (3) If it's a Virgo Development bug, we repair it at no cost. If caused by factors outside our work (client actions, third-party integrations), we charge for triage time. (4) The client is informed of findings and any associated costs.

Disputes

Virgo Development acknowledges an element of risk for both the client and the craftsperson in the execution of the policies outlined above. Virgo Development will work with the client and craftsperson to resolve any disputes in a fair, reasonable way.

As a rule, Virgo Development accepts the risks and costs to resolve cases where a client and craftsperson continue to disagree regarding whether a bug exists, or whether a complete deliverable was made. In cases where we side with the client, Virgo Development will arrange and pay for the resolution. In cases where we side with the craftsperson, we will compensate them to remedy the situation as needed.