Agile Series #2: How to get started with Scrum?

This is part 2 of a 3-part mini series in which we provide you with a short introduction on developing projects using Scrum methods as a recap of the workshop by our mentor Niek Jansma. The first article touched upon the benefits of working with Scrum’s underlying project development framework known as Agile. In this article, team roles and sprint cycles are discussed. Finally, we will provide you with information on what implementing scrum looks like in practice from day to day.

If you are working in a team-oriented job environment, chances are that at some point you have heard the term ‘Scrum’ being intensely discussed. The uninitiated might suspect it to be a brand name for an especially potent cleaning agent to get rid of soap residue (“My bathroom has never been cleaner. Thanks, Scrum!”). Rugby fans will expect a group of players, hugging each other tightly. When you are talking to a Project manager about Scrum however, talking about cleaning or sports won’t get you far.

One widely used method to work agile is to implement the Scrum framework into your product development process. Working with scrum means that all processes are designed to incorporate the agile spirit. Self-organization is at the heart of the scrum approach: everybody needs to be able to realistically assess what they can bring to the table in a short timeframe (like a day or week). To ensure effective communication, each project member is assigned a specific role:

Roles and responsibilities

The Scrum Team
Usually, when you work on a project in scrum, there is a group of 5-9 people (usually developers) involved, who are employed full-time at the same location. They are the ones that will actually build what the product needs. Cross-functionality is important: each contributor is expected to take over different tasks and commit to them.

The Product Owner
Product Owners (PO) are the representatives of the customers that decide what the product is heading towards. The PO manages requests by external parties like customers and investors to prioritize what the scrum team should be working on next. POs have a clear vision of what the product is moving towards and it is their task to motivate the scrum team with clear, elevating goals and let them know exactly what they’re building and why. A Product Owner should not additionally have the Scrum Master’s role, as this can lead to conflicts between team- and customer needs.

The Scrum Master
To make sure the team can complete projects in the right way, as fast as possible, one member takes on the role of the Scrum Master. Masters are responsible for adhering to the Scrum principles, but are not project leaders in the traditional sense. Rather than telling the team exactly what to do, they keep them safe from distractions and help them stick to the scrum principles and focus on their work to be able to work more efficiently. Examples of what they do include managing meetings (described in part 3 of the series) and improving the team’s productivity, happiness and commitment based on the needs of individual team members.


The Scrum Process (Sprint Cycle)

The Scrum Process consists of multiple Sprints. A sprint indicates the time it takes to implement a refinement of the product or build a new feature, from the beginning of planning to the eventual rollout. During the initial setup of Scrum, the duration of a Sprint is determined. The right length of a Sprint can be very different for each team. What matters is that they provide enough time for the completion of every scheduled task. Generally speaking, one Sprint lasts between 2 and 4 weeks, there are however teams who prefer weekly Sprints.

To set a Sprint, the team draws on the so-called Product Backlog. In its core function, the Backlog is a glorified to-do list. All tasks required to deliver the finished product are recorded on this document. It is vital for the team to keep it updated at all times. The Product Owner is responsible for the prioritization of the items- moving the most pressing tasks to the top of the list and describing them in more details, while pushing less important items to the back.

At the start of each Sprint a Sprint meeting is held, in which the relevant Product Backlog units with the highest priority (based on generated business value) are selected by the Product Owner. They are broken down into smaller items, forming the Sprint Backlog. After it is estimated how long each task will take, the duties are assigned to each member. The team then commits to the total amount of work accepted into the Sprint.


Estimating the workload – Planning Poker
One way to find consensus on how much work items in the Sprint Backlog require, is to play Planning Poker. In this method, a set of numbered cards is used, where a high number represents an intense workload. Usually 1 will, for example, represent an estimated one hour of work. Each team member estimates the time a given task will take by playing a card face down. When the cards are revealed, those that offered a card with a high number, discuss the item with those that gave it a lower workload.

Screen Shot 2015-03-13 at 12.16.45Numbers on the planning poker cards

Continue to the final part of the agile series, in which we explain what scrum looks like on a day-to-day basis and introduce some tools to make it easier to get started with scrum in your product development team.

(Images: Julie Donders)

Comments are closed.

Also on Rockstart