Per the Scrum Guide, Developers are the people in the Scrum Team committed to creating any aspect of a usable Increment each Sprint.

That includes coding—but is not limited to coding.

If work does not fit comfortably inside a Sprint with clear acceptance criteria, it is not ready.

The objective is not smaller tasks.
It is small, usable increments that deliver observable value.

You’ll learn how to make quality non-negotiable and routine by turning your Definition of Done (DoD) into concrete, automated checks—so work is “done-done” every day, not “almost done” until the last 24 hours of the sprint.

What this covers

• A practical Definition of Done that’s measurable (not aspirational)

  • Clear acceptance criteria

  • Test expectations (unit, integration, contract/UI where relevant)

  • Code review standards and traceability

• Tests as a daily habit (not a phase)

  • Writing tests alongside code (or just ahead of it)

  • Keeping feedback loops short

  • Preventing regressions and hidden scope

• CI as the enforcement mechanism

  • Build + test pipelines that run on every change

  • Quality gates (linting, coverage thresholds, security scans as appropriate)

  • Fast failures that guide developers to fix issues immediately

Outcomes you should expect

• Fewer “surprises” at the end of the sprint

• Less rework caused by late discovery of defects

• More predictable sprint completion and smoother releases

• A team culture where quality is built-in rather than inspected-in

When DoD is explicit and CI makes it automatic, quality stops being something you “remember to do” and becomes something the system requires—which is exactly how you eliminate end-of-sprint panic.

Key takeaway