Skip to content

Blog

Scrum with AI: what AI changes, and what it doesn’t, in a sprint

· The TIC-NOVA team

At TIC-NOVA, a project moves forward in sprints of 1 or 2 weeks, and every sprint delivers a version you can try. AI does not change that framework. It changes how fast we can keep to it, and it forces us to say clearly who decides.

The framework stays Scrum

We choose the sprint length with you, depending on the project. The work is cut into small increments. At the end of the sprint we show what is done, you adjust the priorities, and we plan the next sprint.

What you receive each sprint is not a progress report: it is the product as it stands that day, ready to use.

What AI speeds up

AI takes part in every stage of the sprint:

  • Coding assistants suggest code; a developer reads it and corrects it.
  • Tests: AI helps write them, then they run without it.
  • Review: AI flags anomalies before the human review, it does not replace it.
  • Documentation is drafted with AI, then checked against the code.

What stays human

AI proposes, humans decide and review. A developer reads every change before it is merged, and the automated tests run before delivery. No secret is passed to AI tools, and a fully local option exists when the context requires it.

That is also why we choose the tool according to your constraints: Claude Code, Codex, GitHub Copilot, Cursor, or models installed on your side, such as Llama and Mistral.

“Done” means security and quality included

An increment is delivered only if it is “done”. For us, that means:

Quality

  • automated tests run on every change;
  • automated end-to-end tests, written with AI;
  • speed, accessibility (WCAG AA) and SEO checked with Lighthouse;
  • screenshots reviewed on mobile and on desktop before every delivery.

Security

  • no secret in the code: keys and passwords live in the delivery server’s variables;
  • every input validated on the server, not only in the browser;
  • personal data minimised: we only collect what is useful;
  • HTTP security headers checked and dependencies audited.

Delivery

  • documentation updated along with the code;
  • a known way back: every deployed version stays available;
  • the code, the documentation and the access rights handed over to the client.

What about the security of an MVP?

It does not depend on the size of the product. An MVP follows the same rules as an application in production: secrets kept out of the code, inputs validated on the server, data minimised, dependencies audited. Putting security off “until later” just means paying more for it, at the worst moment.

In short

AI speeds up writing code, tests and documentation. It replaces neither the review, nor the decision, nor the definition of “done”. That combination is what lets us deliver a quality product, incrementally.

See our method in detail

All articles

Book a 30-minute call