Roles, sprints, artifacts and why short cycles beat big plans
The training regulations for web developers require that students have knowledge of agile development methods and can take part in working communities — it is one of the education's overall goals, not a detail. This is because the requirements for a web solution are rarely completely fixed before work begins. Agile methods are the answer to this: they break work into short cycles where you continuously test, demonstrate and adjust, instead of planning everything in advance and only seeing the result at the end.
Scrum is the most widely used agile framework. According to the Scrum Guide (2020) a Scrum team consists of one Product Owner one Scrum Master and the Developers — without subteams or internal ranking. The Product Owner is responsible for maximising the value of the product and prioritises what will be built. The Scrum Master coaches the team in using Scrum and removes obstacles for them. Developers are everyone who contributes to the finished result — developers testers designers and others.
Work takes place in sprints — short, time-limited periods, often a couple of weeks, with a fixed goal. Around the sprint are four fixed events that should create transparency and the opportunity to adjust as you go.
| Event | Purpose |
|---|---|
| Sprint planning | The team plans what the next sprint should deliver |
| Daily scrum | Short daily status meeting — what is done what is missing what is blocking |
| Sprint review | The finished work is shown, and feedback is gathered |
| Sprint review | The team looks at its own working methods and agrees on improvements |
Scrum is built on three artefacts each with a clear commitment attached to it. The Product Backlog is the complete ordered list of everything missing in the product tied together by a Product Goal. The Sprint Backlog is what the team has concretely chosen for the current sprint bound by a Sprint Goal. The Increment is what has actually been built and works tied to a Definition of Done — a shared understanding of when something is 'done' not just 'written'.
Kanban is another widespread agile approach, often used alone or together with Scrum. Instead of time-boxed sprints, you work with a board-based flow — tasks move through columns like 'not started', 'in progress' and 'done' — and with limits on how many tasks can be in progress at once (WIP limits). It works well for work that comes in continuously, such as operations and support, where fixed sprints can feel artificial.
“Agile methods are not about dropping planning — they are about planning in cycles short enough that you discover the error before it is expensive to fix.”
— Common teaching principle in project organization