Nowadays, Scrum has become the most widely used agile method by companies. Why is that? Because it has proven itself. And if you too want to put it to the test and see for yourself how you can use it to update your project management, here’s everything you need to know about Scrum: ceremonies, roles, and tools. Let’s get started.
What is Scrum?
Scrum is one of the many project management agile methods. As so, it aims at boosting team productivity and velocity, optimizing product value by relying on regular feedbacks from final users.
The name of this method, “Scrum”, was actually borrowed from the rugby world: just like rugby players, Scrum agile team members gather as many times as possible (in… scrums) to check up on the project, always ready to change the initial plan. Therefore, Scrum is a pretty dynamic and always-moving approach that encourages collaborative project management and guarantees the right balance for the client between the planned investment and the final delivered product.
Also, if Scrum has become the most popular agile method among developers, it’s because it promotes the Agile Manifesto values: more collaboration with the client, overcoming the fear of change, putting interaction with people at the center of any project management, and focusing on delivering operational software. But for non-agile teams, Scrum’s framework has its own vocab and particularities that can appear quite complex at first. But no worries, if you feel like getting into it, we’ve got you covered. Put aside everything you thought you knew about Scrum and let’s dig into it!
3 fundamental principles
In Scrum, the goal is to define a clear and precise working framework punctuated by short iterations to facilitate the implementation of complex projects. This specific framework revolves around three fundamental principles:
- transparency: each team members must have access to all information regarding the product to deliver;
- inspection: regular evaluations are essential to readjust the project if necessary;
- adaptation: the implementation of new measures is necessary when inspection shows deviations from the measured results.
The Agile Scrum method defines 3 roles.
They are all complementary and it’s important to understand each one’s responsibilities.
According to the Scrum Master guide, the Scrum Master is a servant-leader for the team, the one protecting the good practice of the method. But beware, he is NOT a project manager! The Scrum Master is actually responsible for promoting and supporting Scrum as defined in the Scrum Guide. How? By helping everyone understand the theory, practices, rules, and values of Scrum… but also by helping people outside of the Scrum Team evaluate the importance of each interaction with them, to understand which of their interactions with the team are useful and which are not. In other words, the Scrum Master’s role is to help everyone improve interactions to maximize the value created by the Scrum team.
In short, we can say that the Product Owner is the bridge between the business part and the technical part of the project. Therefore, he is the link between the client and the development team. The Product Owner carries the vision of the Scrum product. Fully integrated to the Scrum team, he is responsible for writing user stories and for keeping the Product Backlog up to date.
The development team is responsible for transforming the expressed needs into usable functionalities. The team can be multidisciplinary and involve several types of people: developers, software architects, functional analysts, graphic designers, ergonomists, systems engineers, etc.
In Scrum, the lifecycle of a project is punctuated by a set of meetings with a well-defined goal for each of them. Ceremonies such as the Daily Scrum, Sprints planning, Sprint review, and the Retrospective are fundamental tools to the Scrum Master. Let’s see what they’re all about.
To promote collective intelligence while estimating user stories (see below), the Scrum Master uses the “Poker planning”: it enables team members to focus on their own relative and/or collective experience to come up with an estimation in story points. With online tools like Tuleap, once story points are defined, team members can easily enter them in the “user story” service: this will allow them to check out at a glance if they did not exceed the capacity planned for the release and the sprint.
The Sprint Planning meeting is one of the most important steps in a Scrum project. During this meeting, the development team selects the priority elements of the Product Backlog that they think they can achieve during the sprint. This collaborative work of the whole Scrum Team results in the creation of a sprint plan.
The Daily Stand up meeting (or Daily Scrum) is a daily synchronization meeting. The goal is to enable team members to gather daily to discuss tasks progress and potential problems, to overcome possible blockages, and to promote mutual support. To make things more visual and to see the list of all the tasks and the progress of the project, the stand-up meeting often involves a cardwall (see below) or a Kanban board.
The Sprint Retrospective is certainly one key element toward continuous improvement. This reunion takes place at the end of a sprint and, once again, gathers the entire development team. By analyzing graphs (Burnup chart, Burndown chart, Velocity), but also freely discussing and taking a step back from the past sprint, the team seeks improvement and wonders how to optimize even more the interactions between individuals to gain in well-being and motivation, to raise product quality, and overall, to improve its productivity.
How to speak Scrum?
The Product Backlog is definitely a key component of the scrum method, it’s the Product Owner’s playground: as the one in direct relation with customers, the PO is in charge of managing and keeping the product backlog up to date.
The Product Backlog is the beating heart of any product developed in Scrum. You can think of it as a big bag full of user-stories-turned-into-tasks that you can select and plan in your upcoming sprints. Even if it mainly revolves around the Product Owner, it has to be easily shared with the development team.
A sprint is a short period of time – or iteration – of 2 weeks up to 1 month to the max, during which the development team will design, realize and test new features. Several sprints result into a release.
A release means a version of the product is delivered to final users. But a release can also refer to the period of time during which one version is under development, going through successive sprints, until the delivery. To put it simply, a release is the result of multiple sprints.
Generally speaking, an “Epic” is a macro functionality of the product to be developed. Epics can also be described as multiple sets of user stories grouped by categories or themes.
Story points are workload estimation units. They are a way to estimate the effort required to achieve a functionality. But it is NOT a man / day, nor a deadline for completion. A “story point” is an arbitrary measure set by the team. It can take different forms: T-shirt size (XS, S, M, L, XL), numbers from 1 to 10…
A “User story” is not a task, neither a specification. Rather, it is a statement of a user expectation. In Scrum, user stories are narrated according to a defined format: “As (persona), I want to (expression of the wish), so that (goal to achieve).”
Which gives for example: “As a user, I want to be able to delete an item from my basket so that I can update it.”
Tasks, and possibly sub-tasks, are technical activities that helps respond to user stories. Ideally, these activities should be the same size (in the sense of working complexity) but may be of a different nature: design, development, test, etc.
Burndown and Burn-up
The burn-down chart is often used at the sprint level. It allows team members to visualize what’s left to be done and gives a visual survey of the whole rhythm of development.
The Burn-up chart allows to follow the evolution of the amount of finished work over time. One line represents the work already done (in green below), the other the perimeter of the release (in red).
The “velocity” is an interesting indicator in Scrum. It determines the effort that a development team is capable of providing to complete every tasks of a sprint.
The velocity is expressed in a certain number of “points”. To evaluate the amont of “points” required to accomplish a task, we average the number of points delivered over several sprints.
Therefore, the velocity helps with planning.
But be careful, velocity doesn’t mean measuring the performance or productivity of a team. What is important to measure is actually the business value / the quality of the software delivered.
At the planning phase of the sprints, we also focus on the “capacity” of the team. It represents the “availability” of team members during one sprint. Training or vacation periods can, for example, change the overall capacity of the team.
Tips and tools for your Scrum team
Let’s start with…
A clear wall in the workspace
To begin with Scrum, you need a big large board with multiple columns, each representing different phases/statuses of your project.
A very large amount of post-its and big pens
Those are Scrum must-haves.
One post-it = one activity.
And each of them has to be clearly visible and synthetic.
Tips: write short meaningful words in big bold letters.
« Scrum and XP from the trenches » aka The Scrum Bible
The one and only book, written by Jeff Sutherland (co-creator of the Agile Scrum method), will provide you with real leads to set up Scrum within your teams. It’s an essential return of experience to start Scrum, whether or not you are accompanied by an agile coach.
… then comes the time for an online collaborative workspace
Post-its and a big white wall are a great place to start to get used to Scrum… But it only works if team members are all gathered in the same physical space. When teams are distributed or telecommuted (or simply because let’s face it, post-its seems to be made to fall to the ground at some point), an online tool quickly appears like the only working alternative. Yes, we’re talking about software to develop software. But not any software: an agile project management tool, like Tuleap for instance.
History of changes, real-time information, shared backlog, and more: agile project management software brings many advantages. And it comes with the same basic principles fo physical Scrum tools: a cardwall and some post-its that can be easily moved from one column to the other by drag n’ drop. Moreover, an agile software also brings graphs, facilitates the product backlog management and the evolution of user stories, and showcases what’s planned in the next iterations so that everybody’s on the same page.