BEFORE SPRINT— Before you can start coding, you must plan what you'll work on. In Scrum, there are no big master plans like in Waterfall, where you lock up your resources months in advance. Instead, Scrum lets you work on one thing for two weeks and then reflect on what you'll work on next.
Everything starts with your users/clients. First, you get a wish list from your customers in a special format called user story, which looks like this:
• As a (role), I want (feature) so that (reason)
• As a manager, I want custom time reporting services to calculate my employees' exact salaries.
Then, you create a task for each user story, put it in a backlog, and estimate each task (together with the team). Finally, you decide on what items you will work during the sprint. If some item can't be done in one sprint, it's called an epic, and you have three options: split it across several sprints, leave it for later, or do a new project and form a separate team to work on it.
DURING SPRINT— You set up a Kanban board to visually track progress, see who works on what, and control bottlenecks. The board is usually split into several task lists (columns):
• Backlog - all feature requests and bugs go here first
• Next Sprint - tasks you'll work on after the team finishes the current sprint
• To-Do - what the team needs to complete during the current sprint
• In Progress - tasks that the team is actively working on right now
• Testing - finished tasks that need to be tested before being marked as complete
• Done - finished tasks that are ready to be shipped once the sprint end
Once you've decided on what items to work on, the team pulls tasks from the To-Do columns and moves them to In Progress as they start working on them. Once they're finished, the task goes to Testing; if the task needs more work, it goes back to In Progress; once the task meets the Definition-Of-Done criteria, it goes to Done and is ready to be shipped.
Each day before work, the team has a daily standup. The meeting doesn't take longer than 15 minutes, and everyone shares a quick status update:
• Things I have done since yesterday's meeting
• Things I am going to get done today
• Obstacles I need someone to remove
To measure professional progress, the team uses a Burndown Chart, which is a graphical representation of work left to do versus time. That chart shows the team's efficiency, whether they will ship on time, and if the process must be optimized.
AFTER SPRINT— At the end of the sprint, the team reflects on what they've done. They have two reflection sessions:
• Sprint review (2h), where they discuss the work they've done and the planned work they didn't finish
• Sprint retrospective (1h), where they talk about the process (what went well and what could be improved in the next sprint)
After the reflection, the team estimates new user stories and decides on what to work on during the next sprint.
People frequently ask which role can cancel a sprint. The answer is that only the product owner can cancel a sprint if the conditions change significantly or the sprint goal becomes obsolete.