Scrum in Software Projects: Roles, Process and Velocity

Scrum suits software projects in which requirements only become clear through use: the project runs in short, fixed sprints, each ending with a usable result that you can review and reprioritize. Whether that works depends on three things – a Product Owner with decision-making authority, a binding Definition of Done and a sensible approach to velocity.

Scrum is one of the best-known agile frameworks and at the same time one of the most frequently misunderstood. It is sometimes sold as a cure-all, sometimes dismissed as a pointless meeting ritual. This article explains for clients how roles, artifacts and events work together in practice, what the Definition of Done achieves, what velocity is good for and when Kanban is the better choice.

Scrum in software projects: basic principle and roles

Scrum breaks a project into sprints: fixed time boxes of one month at most, in practice usually two weeks. Every sprint ends with an increment, meaning a usable result that stakeholders can see and assess. Instead of fixing all requirements at the start, you check after each sprint whether the direction is still right. The framework is built on transparency, inspection and adaptation – and it lowers the risk of developing past the actual need for months.

In custom software this is especially valuable: many requirements only become tangible once users have a first version in their hands. A sprint rhythm keeps this learning loop short and affordable.

The principle comes with clear roles. Since the 2020 version, the Scrum Guide has described a single Scrum Team with three accountabilities. The earlier distinction between the Scrum Team and a separate “development team” no longer applies; Developers are everyone who works on the increment – for example frontend, backend, design and testing.

Product Owner

The Product Owner is accountable for the Product Backlog and therefore for the order of the work. They decide what gets built next and are a single person, not a committee. In client projects this role ideally sits with you – with someone who knows the business need, is allowed to make decisions and has time on a regular basis. If any of these is missing, the project stalls: questions stay open for days and the team builds on assumptions.

Developers

The Developers combine all the skills needed for a finished increment: frontend, backend, design, testing and operations. They organize themselves and decide how the requirements are implemented technically. They are jointly responsible for quality – not a single tester at the end of the chain.

Scrum Master

The Scrum Master makes sure Scrum is understood and practiced, facilitates the meetings when needed and removes obstacles – such as missing access to test systems or open coordination with third parties. They support the team rather than assigning tasks.

Artifacts and events at a glance

Scrum consists of a few building blocks that support each other:

Building block	Purpose	Time frame per the Scrum Guide
Product Backlog	prioritized list of all known requirements, aligned with the product goal	maintained continuously
Sprint Backlog	the items the team implements in the sprint, with a sprint goal and a plan	created in Sprint Planning
Increment	usable result that meets the Definition of Done	at the end of every sprint
Sprint Planning	selecting the items and formulating the sprint goal	at most 8 hours for a one-month sprint, less for shorter sprints
Daily Scrum	daily alignment among the Developers	15 minutes
Sprint Review	show the result, gather feedback, adjust the backlog	at most 4 hours for a one-month sprint
Retrospective	improve collaboration and ways of working	at most 3 hours for a one-month sprint

Backlog refinement: the underrated groundwork

Refinement is not an event of its own but an ongoing activity – and a crucial one. Items are prepared so that they can be implemented within a sprint: with clear acceptance criteria, clarified dependencies and a rough estimate. If refinement is neglected, Sprint Planning gets spent on fundamental discussions and sprints start with items that turn out to be too big or too unclear.

A sprint in a client project: how it works

1. Sprint Planning: the Product Owner and the team select the most important items from the backlog and formulate a shared sprint goal – one sentence describing the value of the sprint.
2. Implementation: the team develops, tests and aligns in the Daily. The Product Owner answers questions promptly.
3. Sprint Review: the result is shown live – ideally to users from the business department, who give feedback right away.
4. Retrospective: the team discusses what went well and what it wants to do better in the next sprint – with concrete actions.

For you as the client this means: you regularly see real, working software instead of status reports and can adjust priorities before much budget is committed.

Example: a customer portal in sprints

Suppose a trading company has a customer portal developed for orders and invoices. The head of the inside sales team takes on the role of Product Owner and sets aside fixed times every week for questions. The goal of the first sprint is: customers can log in and view their latest orders. In the Sprint Review, two clerks try out the feature and find that without a filter by delivery date nobody can find anything. The item moves up the backlog and is implemented two weeks later – instead of surfacing only in the final test, when changes are far more expensive.

Definition of Done and velocity: quality and planning

Definition of Done: the quality anchor

When is a task truly done? Without a shared answer, misunderstandings arise: for development a feature is “done” when the code runs – for you only when it is tested, documented and usable. A Definition of Done (DoD) creates commitment. It applies to every item, whereas acceptance criteria describe what a single item has to achieve functionally. An example of a DoD:

• The code has been reviewed by a second person.
• Automated tests exist and pass.
• The documentation is up to date.
• Monitoring and logging are set up.
• The feature has been accepted on the staging environment.

Without a shared Definition of Done, technical debt grows invisibly. How to assess and reduce such legacy burdens is covered in the article Prioritizing technical debt.

Velocity: a planning aid, not a performance comparison

Velocity describes how many story points a team typically completes per sprint. Story points are relative estimates: they compare tasks with one another, not with hours. Velocity is not a requirement of the Scrum Guide but a widespread practice – and it is only useful for planning within a single team.

Comparisons between teams are misleading: one point means something completely different in team A than in team B. If velocity is turned into a performance metric, the estimates rise, not the results. For clients, sprint goals and the increments actually accepted are more meaningful anyway.

Planning realistically also means being patient. As a rule of thumb, velocity stabilizes after four to six sprints; reliable forecasts for release dates are only possible after a few iterations. Teams that prefer to work without points count instead how many items of similar size are completed per sprint.

Scrum or Kanban? A decision guide

For clearly defined products with good access to stakeholders, Scrum works very well. It looks different when a project depends heavily on external systems, priorities keep changing or most of the work consists of support and maintenance. In that case Kanban with a continuous flow of work often makes more sense.

Situation	Better suited	Reason
New product or major further development with a recognizable goal	Scrum	sprint goals and reviews steer progress
Operations, support and bug fixing	Kanban	tasks arrive irregularly and are hard to plan in sprints
Priorities change several times a week	Kanban	new tasks can move up without a sprint boundary
Strong dependence on third parties, for example for interfaces or approvals	Kanban or Scrum with buffers	waiting times must become visible and must not blow up the sprint
No Product Owner with time and decision-making authority	clarify the role first	without decisions, any framework lacks a foundation

We choose the framework based on context, not on trends. In many projects we combine both: Scrum for further development, Kanban for operations and bug fixing.

Agile and still plannable: budget and contract

A common worry is: “Agile means we never know what it will cost.” It does not have to be that way. For a clearly defined scope we prefer to offer a fixed price. If the scope is still open, we work with an agreed budget framework and a prioritized backlog – the most important features come first, and after each sprint you can decide whether the current state is enough or further sprints make sense.

A structured requirements specification (Lastenheft) is a good foundation; if you first want to test an idea, start with an MVP. The contract should settle the budget framework, sprint length, the role of the Product Owner, the acceptance procedure per increment and how change requests are handled. Whether it is a contract for work (Werkvertrag) with a fixed price or a service contract (Dienstvertrag) billed by effort within a budget framework: have the structure reviewed by a lawyer.

Typical mistakes and a checklist for clients

Typical mistakes and how to avoid them

• Product Owner without time: decisions are delayed. Block fixed times in the calendar.
• Review attended only by project members: real feedback is missing. Invite users from the business department.
• Sprint length changed constantly: planning and velocity become unreliable. Pick a length and stick with it.
• Velocity as a performance metric: the estimates rise, not the results. Use it within the team only.
• Retrospective without consequences: the same problems keep coming back. Agree on actions with owners.
• Scrum à la carte: uncomfortable elements such as the review or the Definition of Done get dropped, and little of the benefit remains.

Checklist: how to make Scrum work in a client project

• Product Owner with time and decision-making authority appointed
• Sprint length defined and consistently kept
• Regular backlog refinement scheduled in the calendar
• Definition of Done agreed in writing
• Velocity used for planning within the team only
• Sprint Reviews with real users instead of project members only
• Retrospectives with concrete improvement actions
• Budget framework, acceptance procedure and handling of changes settled in the contract

How Nano Concepts can help

Are you planning custom software and want to know which approach suits your project? We choose the framework based on context, not on trends. The initial consultation is free, after which you receive a transparent quote. Our packages offer a starting point: Starter from €2,500, Professional from €8,000 and Enterprise tailored to the individual scope.

This article does not replace legal advice.