Scrum. Manage Projects Agilely.
What is Scrum and how does it work? Who is involved in it? And why are projects meant to be more successful with it?
All the requirements are collected in the product backlog. The product owner is responsible for collecting new ones, estimating priorities and removing old ones. The development team estimates the implementation effort of the requirements.
The development team develops in phases - so-called sprints. A sprint always has a specified length, normally one to four weeks. When a length has been decided, it applies to every sprint.
The development team meets every day for a short chat in the form of a daily Scrum. Each team member reports what they achieved on the previous day, what they want to have achieved by tomorrow and which obstacles might stand in their way. The product owner is often present, even though they are normally a passive participant.
Scrum – the word has a bit of a foreign feel to it. It’s actually a rugby concept. Ikujirō Nonaka and Hirotaka Takeuchi were the first to use the concept to describe successful project development. The success of a project, according to Nonaka and Takeuchi, is above-all dependent on the team and the tactics that the team uses: They will work more efficiently if they are following one goal and can organize themselves to reach it. Later, Ken Schwaber and Mike Beedle took the concept and in 2001 published the first book about Scrum in software development. Today, it is one of the most well-known processes in agile project management and offers official guidelines in the Scrum Guide. These guidelines can be applied not just to software projects, but to all projects that deal with a complex task. So, how does agile project management work with Scrum?
The Accountabilities (Formerly Roles) in Scrum
Scrum follows the values that were put forward in the 2001 agile manifesto and a new type of project management was established. It says that rigid schedules, insufficient communication and inflexible processes don’t lead to successful projects. Instead, we should continually adapt to changes and operate agilely by reinventing the team as a self-organized unit. Here, Scrum relies on three accountabilities that one or more people in a project can take on: development team, Scrum master and product owner. Another important group of people is the stakeholders, although the process doesn’t explicitly define it as a role. In Scrum projects, there is no project leader.
Development Team
Scrum doesn’t work without a development team. Ideally, the team consists of three to nine people and organizes itself. If more people are needed for development, then the Scrum of Scrums is used: here, multiple development teams are formed, and each takes care of their own product backlog and has their own daily Scrums. In an ideal development team, the expert roles are no longer necessary. The team no longer consists of the analyst, the system architect, the tester: all team members take on these roles and more when it’s required.
Product Owner
The product owner takes care of the project requirements. To do so, they communicate with all the stakeholders and collect the requirements in the product backlog. They don’t just bring the requirements together but also prioritize them, add new ones and discard of others over the span of the project.
Scrum Master
The Scrum master ensures than all the Scrum processes are used properly and the roles are kept to. Apart from that, they also moderate the Scrum meetings and protect the team from unjustified interventions during the development. They can’t be mistaken for a project leader, because the team organizes itself and communicates directly with the product owner.
Product Owner
Stakeholders are not a defined role in Scrum, but they are still relevant to the process, because the people in this category, like customers, employees or managers, and legal personnel or institutes, are interested in the project’s success. The product owner determines fitting requirements and priorities through the stakeholders.
How Scrum Works in Practice
Learn more about agile project management here with objectiF RPM »
Everything Begins with the Requirements – the Product Backlog in Scrum
Scrum comes under agile development processes and even requirements are determined agilely. Because of this, the process uses the so-called product backlog: there, the product owner collects all of the project requirements that the development team has to implement. Here, a product always refers to an exact result to be realized – for example, a piece of software. If the team has to develop different pieces of software, then there are different product backlogs.
The product owner determines the requirements based on the feedback of the stakeholders and prioritizes them according to business value. They then produce a list where requirements are sorted according to their priorities. If changes occur during the project, then the product owner adapts this list – a product backlog is not fixed, it is always changing. The requirements established there are also normally described in the form of user stories and broken down into individual tasks.
Click here to learn more about backlogs, user stories and tasks »
From Sprint to Sprint – Project Management with Scrum
The development team doesn’t just implement the requirements without a plan – they consider the outer structure, because a Scrum project is structured in so-called sprints and releases. A sprint consists of a development cycle of one to four weeks. The exact length is determined by the team, a sprint should always be the same length. Multiple sprints result in a release, where a functioning product version is released.
During a sprint, the development team works undisturbed.
In this time, the product owner cannot change the requirements.
When the first product backlog is available, then the team and the product owner put it together in a sprint planning. Here they decide which goals are planned for the next sprint and which requirements have to be implemented. The development team estimates the implementation effort of each requirement i.e., user story. On the basis of this estimation of effort and of the priorities that the product owner has given, the development team selects a number of requirements for the next sprint – a so-called sprint backlog emerges. The developers have to implement all the user stories that contain this backlog contains in this sprint. Progress is captured in that the remaining effort is noted every day. This way, the remaining effort of a requirement decreases to zero at the end of the sprint: the user story has been implemented. Such a development can be nicely presented in a so-called burn down chart.
At the end of the sprint, the team meets for a sprint review, which shouldn’t last longer than an hour. The developers discuss their results and see if they have reached the strived-for goal. The stakeholders also take part in this meeting and give active feedback. The product owner works over the product backlog and together with the team plans the goal and the requirements for the next sprint.
To conclude the sprint, the team carries out a sprint retrospective under the moderation of the Scrum master or another moderator. At least one suggestion for improvement regarding the sprint should be put forward.
Sprint Planning
- Determine goal of the next sprint
- Estimate effort of the user stories
- Plan the user stories for the next sprint
Sprint Review
- Team: present sprint results
- Product owner and stakeholders: give feedback
Sprint Retrospective
- Collect facts and data
- Gain knowledge
- Decide on improvements on the process
Communicate, Communicate, Communicate – in the Daily Scrums
Scrum thrives on vibrant communication – not just between stakeholders and the product owner, but also within the development team. Because of that the developers come together at the beginning of every work day for a daily Scrum meeting: in a maximum of fifteen minutes, the participants report what they achieved yesterday, what they want to achieve before the next daily Scrum and which obstacles might stand in their way. When problems occur, the team members help each other when needed. Even the product owner and the Scrum master are often present, even if they are only passive participants.
The meeting normally takes place whilst standing. It is important that the team members are really reporting to each other, not receiving orders from superiors. In the end, it is not about sitting on one’s own ivory tower, but rather about keeping an overview of everyone else’s work.
If there are multiple development teams, then after the daily Scrum, a meeting between the different teams takes place in a Scrum of Scrums. They also inform each other about the current state of their team. Not all members have to participate, just one or two defined people per team.
Each Team Member Answers the Questions:
What have I done since yesterday?
What will I do tomorrow?
What is preventing me from doing my work?
Scrum is really popular. And that’s no wonder:
The clear distribution of roles and simple structure makes it
possible to learn the principles quickly, efficiently implement them
and to really live agile project management.
Manage projects agilely with Scrum
As the product owner you have to set up requirements, add new ones quickly and be able to remove expired ones, so that the product backlog remains current. You have to plan sprints and releases like the associated backlogs to be able to deliver your project on time. The developers are responsible for recording the progress of your work, so that the current sprint and project development can be evaluated. But how do you keep an overview? How can requirements be created efficiently, prioritized and estimated? How can you keep the progress of the implementation traceable? And wouldn’t it be helpful to be able to create diagrams, like burndown charts, with hardly any effort?