Scrum: Theory and practice

Scrum is an agile methodology that organises work is small increments and that focuses on the continuous delivery of usable solutions. In this post I talk about Sprints, the heart of Scrum, and describe the roles, artefacts, and ceremonies that form it. I eventually add in tips based in my experience that aim to help you successfully adopt this methodology in your product and software development teams.


In SCRUM projects are divided in sprints: short, time-boxed efforts with a clear goal in mind, at the end of which the team delivers a piece of working software and takes time to look back to learn for the next sprint.

At the beginning of each project a decision should be made as to how long sprints will last. It’s a good practice to keep the length of sprints constant, as it gives a constant pace and a feeling of rhythm to the project.

A typical sprint lasts two weeks. Some teams have longer sprints (I have seen sprints up to six weeks long) and some have short one-week sprints. Scrum teams are encouraged to self-organize and go for whatever works best for them.



A SCRUM team consists of the developers, designers, QAs, and devops that work together in a product or module. SCRUM does not conceive design teams or QA teams, and instead talks about team made of people with different specialisations. In scrum, a team is a team is a team.


The SCRUM master supports the SCRUM team organising the meetings, keeping notes, assigning tickets, tracking velocity… S/he is also responsible for avoiding interruptions to the team during the sprint. This is a serving role, far from the typical idea of project managers.


The product owner works with one or more sprint teams providing the scrum master requirements in the form of user stories and clarifying them as needed. S/he is also the person delivering the sprint products to the clients and stakeholders and collecting feedback from them.

The product owner is a Scrum Role. There are no Product Managers in Scrum, although a Product Owner working with a Scrum team may have the Product Manager title in the company and do that function in the project as well. It is complex, but it is what it is.



The product backlog is the set of user stories that define the deliverable. User stories are a great way for customers and team members to define what a product should do, because they focus on the problem that needs to be solved or the benefit wanted instead of focusing on the specifics of the solution.
User stories are written during the whole lifecycle of the project and are managed and prioritised by the product owner.


The sprint backlog is the set of user stories assigned to the next sprint by the product owner together with the scrum master and the scrum team in the sprint planning meeting. The sprint backlog must be achievable in the length of the sprint and should contribute to the sprint goal.

Sometimes a sprint will end and some tasks from the sprint backlog will still be in progress or in the To Do column of the Kanban board. This indicates either that an unexpected resources shortage happened (for example if a team member was sick or there were many unexpected meetings) or that the sprint was over ambitious. While it is not a big deal, it must be looked into.


The burndown chart is a graphical representation of the team velocity. It is a curve with the sprint length in days on the x axis and the story points remaining on the y axis. A descending diagonal represents the ideal velocity – a constant reduction of pending story points along the duration of the sprint.

This tool is useful for project managers to know when the speed needs to be increased, or to identify days in which more or less work is done.



The sprint planning meeting opens each sprint.

The product owner presents the sprint goal to the team. The product owner is in constant communication with the client and stakeholders to collect their new requirements and feedback on released functionality and knows the backlog and its dependencies, allowing them to plan the pack of work that needs to be delivered next.

Based on the sprint goal proposed by the product owner the SCRUM Master sorts items in the backlog per priority and observing dependencies and the team estimates the effort needed to complete them.

Once the sprint candidate is estimated the number of points can be compared with the team velocity of the previous sprints to see if the sprint has a realistic amount of work. The goal is not to plan as much as possible, but to plan a realistic amount of work that will help move the product forward and keep developers busy for the length of the sprint but also be realistic enough to be finished in full (and as in done-done) by the end of the sprint.

4-8hScrum Master
Product Owner
Scrum Team
Product Backlog
Team Capacity
Sprint Goal
Sprint Backlog


In scrum there is a daily meeting in which all team members share their progress in the day before, their plans for the current day, and whether there are any blocks to it or they need the assistance of another team member to accomplish it.

It is a good idea to have this meeting happen at the same time everyday, and it’s a common practice to hold it in the morning.

In order to keep this meeting short the daily scrum meeting is usually a standup meeting: team members stay up, usually meeting by a kanban board, and don’t get into specifics. The ideal length of this meeting is 15m, and it should be a very agile one: it is not the place for announcements, technical discussions or conflict resolutions.

It is a good practice to take notes so that the progress can be shared with other members of the organisation not attending the meeting or as a way of keeping track of what’s going on for future reference (i.e. when preparing post-mortems).

15mScrum Master
Product Owner
Scrum Team
Yesterday’s work
Today’s activities
Standup notes

If you work with a remote team or mostly with freelancers standing up in the same room can be hard to achieve, but you can use technology to fill in the gap. Use google hangouts or skype to get everyone on a call or as team members to share their standup notes on slack. You could even automate this using this clever hack


At the end of each sprint the team gets together to go through the stories planned for the sprint and define whether or not they are considered resolved. Ideally the team will go through the features that make the story possible in the staging environment to collect feedback and verify the story is done-done


After the sprint review meeting the team gets together to discuss team dynamics during the sprint. There are different retrospective dynamics but generally a retrospective should cover all things that went good and bad, as well as things that are neither good or bad but that the team wants to make part of the discussion and history of the project.

Based on the results of the retrospective the team sets actions to fix the bad things or replicate the good ones. It is a good practice to document these retrospectives and the decisions made for future reference.

2 responses to “Scrum: Theory and practice”

  1. […] a list of related work items that are feasible within the time and capacity of the team. You can read more about Sprints in this blog post. Each Sprint has an associated Sprint Backlog, a section of the Product Backlog with a lot more […]

  2. […] a list of related work items that are feasible within the time and capacity of the team. You can read more about Sprints in this blog post. Each Sprint has an associated Sprint Backlog, a section of the Product Backlog with a lot more […]

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s

%d bloggers like this: