Relative sizing
Stories are sized against each other by the engineers who will build them, not by a sales estimate.
Agile Software Development
Agile software development services
Your requirements will change once real users see the product, and a plan fixed months ago will not survive that. Agnotic Technologies builds software in short sprints with a shared backlog, demos of working software and a written definition of done, so you can change direction without losing control.
Fixed-length sprintsWeekly demosDefinition of doneCI on every change
Trusted by global innovators
Agile delivery
What is agile software development?
Agile software development builds a product in short, fixed-length sprints, each ending in working software that users and stakeholders can review. At Agnotic Technologies, agile delivery means a shared backlog your product owner prioritizes, sprint planning, weekly demos, a written definition of done and continuous integration on every change.
The plan is still real: there is a first release goal and a forecast. What changes is how often you see progress and how cheaply you can change direction.
Agile is a way of running the work, not a reason to skip specs, tests or security. Those are part of done on every item.
Decision table
When does agile fit, and when is fixed scope better?
We recommend fixed scope when it fits. These are the signals we look at on the scoping call.
| Signal | Points to agile delivery | Points to a fixed scope |
|---|---|---|
| Requirements | Expected to change once users see the product | Known, stable and written down |
| Product owner | Available every sprint to prioritize and accept work | Available to sign off the scope and the final release |
| Budget | A monthly budget with the scope adjusted to fit | A single agreed budget for a defined result |
| Risk | Unknowns in users, integrations or technology | Well understood work, such as a migration or a defined feature |
| Contract | Time and materials with sprint reports | A fixed price for an agreed scope |
| After launch | Continues as a product roadmap | Ends, or moves to maintenance and support |
A common pattern: a fixed-scope first release to launch, then agile delivery for everything users ask for next.
Sprint cycle
What happens in each sprint?
The same five events run every sprint. Sprint length is agreed at the start of the engagement and then kept fixed.
1.
Backlog refinement
The team and your product owner split upcoming items into small, testable stories with acceptance criteria.
Refine2.
Sprint planning
We agree a sprint goal and pull in only the work the team can finish to the definition of done.
Plan3.
Daily stand-up
A short check on progress and blockers, with decisions written in the tracker for anyone who missed it.
Sync4.
Weekly demo
Working software in a shared environment, never slides. You accept, adjust or reprioritize on the spot.
Demo5.
Retrospective
The team reviews what slowed it down and agrees one or two changes for the next sprint.
ImproveDefinition of done
Our definition of done
An item counts as done only when every line below is true. This checklist is shared with you in week one and can be extended for your product.
- Acceptance criteria met and checked by someone other than the author
- Code reviewed and merged through a pull request with passing automated tests
- New logic covered by unit or integration tests
- No new high or critical findings from dependency and code scanning
- Deployed to a shared staging environment and shown in a demo
- Accessibility checked against WCAG 2.2 for any new interface
- Documentation, API specs and runbooks updated where behavior changed
Continuous integration
What happens between a commit and a demo?
Continuous integration is what makes short sprints safe. Every change follows the same path.
Small branch, small change
Engineers commit small changes often, linked to a backlog item.
Automated checks
The pipeline builds the code, runs tests, lints and scans dependencies on every push.
Peer review
A second engineer reviews the pull request; protected branches block merges without review and green checks.
Staging deploy
Merged work deploys to a shared staging environment automatically, ready for the demo.
Release when accepted
Production releases follow your product owner's acceptance, with a rollback path for each release.
Estimation
How do we estimate without a fixed price?
We do not publish prices or promise dates before the scope is known. Agile estimation gives you a forecast that gets sharper every sprint.
Ranges, not single dates
Forecasts for a release are given as a range that narrows as the team's pace becomes clear.
A first release goal
We agree what the first release must contain, and track the backlog against that goal every sprint.
Budget guardrails
You set a monthly budget; when new work arrives, something of similar size moves out or the budget changes by your decision.
Re-forecast every sprint
The sprint report shows done work, remaining work and the updated forecast, so surprises surface early.
Fixed price where it fits
Well defined pieces, such as a migration or integration, can still be fixed in scope and price inside an agile engagement.
Standards
Standards behind our agile delivery
References for how we run sprints and keep quality and security part of every item.
Agile ManifestoScrum GuideNIST SP 800-218WCAG 2.2OpenAPI
Who it fits
Agile delivery for startups and enterprises
The sprint cycle is the same; the setting around it changes.
Startup founders
Agile software development for startups means learning from users quickly, with a first release goal that keeps the backlog honest.
Enterprise product teams
Sprints that fit your release calendar, change process and reporting, with demos for each stakeholder group.
Teams moving from fixed projects
A gradual switch: one product area runs in sprints while the rest finishes its fixed plan.
Regulated products
Compliance work such as access reviews and audit logging sits in the backlog and the definition of done, not in a final phase.
Facts and sources
Facts and sources behind agile delivery
The primary documents behind how we run sprints and keep security in them, each linked to its source.
The Manifesto for Agile Software Development values individuals and interactions over processes and tools, working software over comprehensive documentation, customer collaboration over contract negotiation, and responding to change over following a plan.
Source: Manifesto for Agile Software DevelopmentOne of the twelve principles behind the Agile Manifesto is to deliver working software frequently, from a couple of weeks to a couple of months, with a preference for the shorter timescale.
Source: Principles behind the Agile ManifestoThe Scrum Guide defines the Definition of Done as a formal description of the state of the Increment when it meets the quality measures required for the product, and describes Sprints as fixed length events of one month or less.
Source: The Scrum Guide (2020)NIST SP 800-218 notes that few software development life cycle models address security in detail, so the SSDF is a core set of secure development practices meant to be integrated into each SDLC implementation, agile included.
Source: NIST SP 800-218, Secure Software Development Framework
Frequently Asked Questions
Scrum-style sprints are our default for building new features, because they give you a regular demo and forecast. Kanban suits work that arrives unpredictably, such as maintenance and support, and some teams combine the two.
It depends on the scope you want in the first release and how it changes after users see it. We agree a first release goal on the scoping call and give a forecast range that is updated every sprint.
For a whole product, usually not, because the scope is expected to change. Well defined pieces, such as an integration or a migration, can be fixed in scope and price inside an agile engagement. Otherwise you control cost through a monthly budget.
A product owner who can prioritize the backlog, attend sprint planning and the weekly demo, and accept or reject finished work. Without that person, agile delivery slows down, and we would suggest a fixed scope instead.
Yes, and many products do. The fixed-scope first release gets the product launched; after that, agile sprints handle the changes that real users ask for.
Security checks are part of the definition of done: dependency and code scanning in the pipeline, peer review of every pull request and threat modelling for new features, in line with NIST SP 800-218. Nothing waits for a final security phase.
Engineers use AI coding tools for drafts, tests and reviews, and every change still meets the same definition of done: human review, passing tests and a demo. AI never merges or deploys on its own.