Project & Development
Agile Development for Beginners: Scrum Roles, Events and Artifacts in Your First Sprint
Beginner | 2 whiteboard pages · Task board: 5 columns (4 parent tasks, 12 subtasks)
Beginner: No technical terms. Just answer the whiteboard's questions, following the examples, and it takes shape.
Anyone new to agile development or joining their first Scrum team uses this beginner template to learn the 3 roles, 5 events and 3 artifacts and to run a first two-week sprint. The whiteboard lays out what agile development means, the 5 steps of a two-week sprint, three frames for the 3 roles, three frames for the 3 artifacts, a table of the 5 events, four MoSCoW columns that pick what fits this sprint, and a KPT retrospective. The task board has five columns - Product Backlog, Sprint Backlog, In development, Waiting for review and Done - and starts with 4 parent tasks and 12 subtasks, from learning the terms to review and retrospective, all not started. Join a team without knowing how Scrum works and the vocabulary leaves you behind, so follow this board from top to bottom for one sprint and you will also know what to say in the daily scrum. Unlike a board for teams already running sprints, this one is about the terms and the first cycle.
Once you have a free account, you can copy this template from the marketplace
Whiteboard preview
Read the whiteboard text as plain text
Agile Development Starter Kit
How to use: (1) Read what agile means → (2) Follow the two-week sprint flow → (3) Check the 3 roles and the 3 artifacts (boards 3-8) → (4) Set the dates of the 5 events (board #9) and use MoSCoW to sort what goes in and what waits (board #10) → (5) Look back with KPT (board #11)
1. What agile development is (build, show and fix in short cycles)
- In one sentence In a short period of about two weeks, build something that works and show it, collect feedback and fix it. Then repeat.
- How it differs from the old way e.g. instead of settling every specification before you build, you decide the build order and work down it a little at a time. The order can change later.
- Why it helps e.g. you see the real thing every two weeks, so if the direction is wrong you notice within two weeks. You only redo one sprint of work.
2. The two-week sprint flow (the daily scrum repeats every day)
- 1. Sprint Planning Day one of the sprint. Sort what to build in the two weeks with MoSCoW on board
- 2. Development (two weeks) Build only what you selected. Even when a new request arrives, as a rule it does not enter this sprint. e.g. work only on the 3 login items, 13 points.
- 3. Daily Scrum (15 minutes a day) Every day of those two weeks, 15 minutes at a fixed time. Each person says what they did yesterday, what they will do today and where they are stuck. It repeats daily alongside the development. e.g. standing up at 10 every morning.
- 4. Sprint Review The last day. Show working software to stakeholders and collect feedback. Up to 2 hours. Show the screen, not the slides. e.g. click through the new login screen live.
- 5. Retrospective Right after the review. Look at the way you work rather than at what you built. Up to 1.5 hours. Decide the next single step with KPT on board
3. Product Owner
- The person who decides what gets built first
- Owns the order of the Product Backlog
- e.g. decides that login fixes come before everything else
- The person to ask whenever the content is unclear
4. Scrum Master
- The person who watches that the way of working is kept
- Removes blockers and keeps each event inside its time box
- e.g. takes in an interrupt request and reschedules it
- Not there to give orders, and not necessarily a manager
5. Developers
- The people who build, including design, coding and testing
- What fits in two weeks is estimated by the developers themselves
- e.g. three people share out the Sprint Backlog
- Developer here is the name of a role, not a job title
6. Product Backlog
- Everything you want to build, in the order it will be built
- Higher means sooner. The Product Owner sets the order
- e.g. login fixes / notification settings / admin search
- A list with no end. It may grow along the way
7. Sprint Backlog
- Only what you agreed to build in these two weeks
- Chosen in planning, and nothing is added mid-sprint
- e.g. the 3 login items, 13 points in total
- It also shows who is holding what
8. Increment
- The working thing that exists at the end of the two weeks
- Anything that misses the definition of done (the conditions the team agreed on in advance for calling something finished) is not part of it
- e.g. the login fixes, tested and checked
- This is what you show in the Sprint Review
9. The 5 events at a glance
| What happens | Who attends | Time box | |
|---|---|---|---|
| Sprint | Sprint The two-week box that holds the other four. The length never grows mid-way. | The whole Scrum team (Product Owner, Scrum Master, Developers) | Two weeks Fixed, one month at most |
| Planning | Sprint Planning Pick what to build in the two weeks and create the Sprint Backlog. | The whole Scrum team | Up to 4 hours Morning of day one |
| Daily Scrum | Daily Scrum Say what you did yesterday, what you do today and where you are stuck. | Developers (the other two roles listen) | 15 minutes Same time, same place, daily |
| Review | Sprint Review Show working software and collect feedback. The screen, not the slides. | Scrum team plus stakeholders (requesters, users) | Up to 2 hours The last day |
| Retrospective | Sprint Retrospective Look at the way you work rather than at what you built. | The whole Scrum team | Up to 1.5 hours Right after the review |
10. Pick what goes into these two weeks (MoSCoW)
Must (essential)
- Only what the sprint goal cannot be reached without. e.g. fixing the bug where the password reset email never arrives
Should (important)
- Important, but the goal still holds if you leave it out this time. e.g. rewriting confusing error messages
Could (if there is room)
- It goes into the sprint, but it is the first thing dropped if time runs short. The goal holds without it. e.g. swapping the logo on the login screen
Won't (not this time)
- Agreed not to do. Do not delete it, keep it in the Product Backlog (board #6). e.g. notification settings and admin search move to a later sprint
11. Looking back on the first sprint (KPT)
Keep (what to continue)
- Fixing the daily scrum at 10 every morning got everyone in the room
- Saying blockers out loud on the spot cleared them within half a day
Problem (what did not work)
- 5 of the 13 points we picked did not finish inside the two weeks
- We could not turn down mid-sprint requests, so the Sprint Backlog swelled
Try (what to try next)
- Start the next sprint at 8 points and add more only if room is left
- The Scrum Master takes in every interrupt request first
Task board contents
Product Backlog 16 items
Learn Scrum terms
The first stumble is always the vocabulary. Learn it as three bundles - roles, events and artifacts - and you stop getting lost in conversations.
List the 3 roles
Write down by name who the Product Owner, the Scrum Master and the Developers are. If someone holds two roles, say so.
Line up 5 events
Put Sprint, Sprint Planning, Daily Scrum, Sprint Review and Sprint Retrospective in time order and add the date and time of each.
Check 3 artifacts
Confirm where the Product Backlog, the Sprint Backlog and the Increment each live.
Plan first sprint
Memorising terms is not enough. Fix a two-week box and go as far as picking only what fits inside it.
Set dates and days
Decide the start date, the end date and the weekday and time of each event. Never stretch the length once it has started.
Fill the backlog
Put everything you want to build into the Product Backlog column and sort it into the order you will build it. The Product Owner owns that order.
Pick 2 weeks only
Working from the top, move only what finishes in two weeks into the Sprint Backlog. If it is too much, use MoSCoW on board
Run daily scrum
The daily routine during the sprint, also called the stand-up. Keep it from turning into a status report and use it to surface blockers on the spot.
Yesterday and today
Each person spends one minute on what they did yesterday and what they will do today. Detailed discussion happens after the daily scrum.
Raise blockers now
Always say out loud where you are stuck. The Scrum Master picks the fix up after the daily scrum.
Move cards on board
Move cards into In development, Waiting for review and Done so that what is left is visible at a glance.
Review and retro
The close of the two weeks. Keeping feedback on the product separate from feedback on the way you work is the Scrum pattern.
Show working demo
In the Sprint Review, show stakeholders a screen that actually works rather than slides, and collect their feedback.
Feedback to backlog
Turn the feedback you got into cards back in the Product Backlog column, as material for the next round of ordering.
Pick one KPT Try
In the retrospective, review the way you work and decide on exactly one Try for the next sprint.
