March 7, 2021


News for Agilists

You’re a Project Manager and Your Company Decides to Adopt Scrum — What Should You Do? | by Willem-Jan Ageling | Serious Scrum | Sep, 2020

First I want to highlight an important difference between Product Management and Project Management.

Product Management is about developing and sustaining a product. It follows the complete lifecycle. Product Management is a continuous effort to get the best value out of the product.

Project Management sets a target of reaching a specific goal in a limited timeframe and a specific budget. This could be:

  • the launch of a new product;
  • adding new features to a product;
  • decommissioning of a redundant product.

These three examples are all pieces of the puzzle that makes Product Management. Projects and products can go hand in hand. Many organisations develop their products by running projects.

Scrum works with Sprints. You could define these as mini-projects, but without the traditional project characteristics. Sprints are no longer than a month, often 1 or 2 weeks only.

At the end of every Sprint, the Scrum Team and the stakeholders discuss what to do next as input for the next Sprint. When a product is at the end of its lifecycle, it is here where they can decide to stop working on it.

Responsibilities of a Project Manager also exist in Scrum. These responsibilities are with the Product Owner, the Scrum Master, the Development Team and/or their stakeholders. In this section, I will discuss them and present where they exist in Scrum.

Responsibility for the success of the project

A Project Manager is responsible for the success of the project. In Scrum, the entire Scrum Team (Product Owner, Development Team and Scrum Master) is responsible for the success of the Sprint, their project. Let me show you how that works.

A Product Owner has the responsibility to ensure that teams work on the most valuable topics. He/she needs to propose a Sprint Goal and the set of Product Backlog Items that help meet this objective.

The Product Owner and Development Team together negotiate and determine the Sprint Goal.

The Development Team is responsible for a plan to achieve the Sprint Goal and also for reaching this goal. The plan isn’t fixed. Instead, it emerges during the Sprint whenever the Development Team gains new insights.

The Scrum Master assists the Development Team to remove blockers and helps ensure transparency on the Sprint Backlog so that everyone knows what they have done, what still needs to happen and if they need to adjust course.

As you can see, everyone in the Scrum Team has a part of the responsibility of the success of a Sprint.

Stakeholder Management

Stakeholder management is everything you need to do involving your stakeholders. These are the people that have a vested interest in your product. Examples are clients, users, management, colleagues, operations, architecture.

A Project Manager identifies stakeholders, creates a strategy to work with stakeholders, aligns with stakeholders, communicates about the progress, ensures that the stakeholder accepts the product.

Within Scrum, this typically is the role of the Product Owner. The Product Owner should order the Product Backlog with the desires and expectations of the stakeholders as one of the inputs. This requires many of the stakeholder management aspects.

The Sprint Review exists to align with the stakeholders. It is here where the Product Owner and the rest of the Scrum Team show what they have built and discuss if it meets the expectations and needs. The participants also bring forward new insight on the marketplace or potential use of the product, impacting the decisions on what to do next. On top of that, it is the place where the Scrum Team and stakeholders discuss timelines and sometimes even budget. If the budget is not part of the Sprint Review, it is a responsibility outside of Scrum.

But not all aspects of stakeholder management are a responsibility for the Product Owner. The Scrum Master also has some responsibilities. She/he helps stakeholders understand Scrum and with that how to best engage with a Scrum Team.

At the start of the project, a Project Manager spends most of the time and energy in creating a Project Plan that details out the steps to reach an objective. This includes a cost breakdown and detailed timelines for the complete project.

Scrum doesn’t work with detailed plans beyond a Sprint. That doesn’t mean that there’s no planning in Scrum. On the contrary, Scrum involves a lot of planning.

It starts with the ordering of the Product Backlog. The Product Owner is responsible that it exists and that the Product Backlog Items are in the right order. Typically a Product Backlog is tightly aligned with the product vision and product strategy. A Product Backlog can translate into a Product Roadmap with rough timelines. However, in Scrum environments, it is unwise to commit beyond a Sprint due to the complex nature of the product.

Only items that the Scrum Team expects to work on soon will be refined. This means that the teams add details and estimates to these items. The estimates come from the Development Team because they will do the work. With that, the Development Team knows enough to start working on those Product Backlog Items.

Every Sprint the Scrum Team sets a Sprint Goal. Based on the Sprint Goal, the Development Team decides what they need to do to meet this goal. The Development Team is responsible for planning their work.

Every day, the Development Team checks the progress towards meeting the Sprint Goal. When deviations occur, the Development Team needs to change its plan accordingly.

Planning is a responsibility for the Product Owner and the Development Team. The Product Owner focuses on the bigger picture and this translates into a Product Backlog. The Development Team is responsible for planning their work in a Sprint and for meeting the Sprint Goal.

Monitoring and Control/Change Management

Traditional project approaches are change-averse. Project managers aim to stick as close as possible to the plan. Scrum is different. Scrum embraces change. This is why Scrum Teams work with increments and in Sprints. They take small steps, evaluate and then decide what to do next. This can be a different direction than expected. But that is fine. It is the way Scrum works.

Responding to change is even ingrained in the daily routine. Scrum Teams work with a Sprint Goal and have the liberty to adjust the course, if required, to meet the Sprint Goal. Scrum embraces the unknown.

Scrum does have some mechanisms of monitoring and control. The purpose of the Daily Scrum is about monitoring progress and maybe replan if needed.

Another event that comes to mind is the Sprint Review. However, here the Scrum Team and the stakeholders don’t monitor and control based upon an existing plan. Instead, they prepare for the next planning session, the Sprint Planning.

Monitoring and Control are largely absent in Scrum. It only exists to stay on track to meet the Sprint Goal. This happens at the Daily Scrum by the Development Team.

Risk Management

Project Managers also need to ensure that project risks are properly identified, analyzed and are properly mitigated.

Scrum addresses risks differently. By working in short iterations teams are more predictable and focus on the items that bring the highest value. Every Sprint, the Scrum Team and its stakeholders discuss the product increment and other aspects that may influence the next best step. This way Scrum helps to avoid moving in the wrong direction for too long. It helps to stay away from the major issue with traditional projects, where only at the end of the project everyone comes to realise that they worked on the wrong things. Scrum helps to avoid draining money and hours for nothing.

Another way to reduce risks is to have artifact transparency. When transparency of Product Backlog, Sprint Backlog and the Increment is complete, teams and stakeholders have the best opportunity to make decisions with the least amount of risk involved.

Here are two examples of incomplete transparency that can lead to wrong decisions:

  • The Development Team hasn’t finished working on an item, but still present it at the Sprint Review. Stakeholders may think it is already finished. They could be disappointed by what they see and dismiss it for the wrong reasons.
  • The Product Owner has a Product Backlog with new features and a Shadow Backlog with technical debt. The stakeholders are not aware of this. Product Owner and stakeholders are not on the same page on what to do next. Stakeholders may be disappointed about the progress, not knowing that the Scrum Team also works on technical debt items.

Scrum Masters need to help ensure artifact transparency. With that, Scrum Masters play a crucial role in risk management.

Quality management

In Scrum, quality is most notably an aspect of the Definition of “Done” (DoD). The Development Team is responsible for the DoD and thus for the quality of what they build. They need to verify what they built using the DoD. They will not mark an Increment as complete unless it meets the Definition of “Done”.

Often the DoD is not enough. Typically Product Backlog Items have acceptance criteria. A Product Owner would be in the lead of determining these acceptance criteria and would also verify if an Increment meets these criteria.


A Project manager controls the implementation of approved changes. In Scrum, it is the Product Owner who decides this when an Increment adheres to the Definition of “Done”.

Project closure

Scrum is a Product Development framework and as such, there is no project closure stage. A new Sprint starts immediately after the previous one ends. At the end of a Sprint two events bring closure to a Sprint:

  • The Sprint Review — Scrum Team and stakeholders discuss what the Development Team built and decide what to do next. One of the possible decisions is to stop sprinting when there is no reason to proceed with the product. This typically marks the end of the lifecycle of a product.
  • The Sprint Retrospective — Scrum Team discusses learnings from the previous Sprint to improve their way of working in the next Sprint.

Scrum is a way to create and sustain products while traditional project management methodologies are about reaching a goal in a set timeframe.

The role of Project Manager doesn’t exist in Scrum. However, the Project Manager responsibilities do exist, although in different shape and form.

Responsibilities that address the product vision, ordering of items, the bigger picture and stakeholder management are largely for the Product Owner.

Responsibilities like planning, monitoring and quality are largely for the Development Team.

The Scrum Master also has a role, mainly targeting risk management and stakeholder management.

If you are a Project Manager and you wish to find a new role within Scrum, then there’s no easy answer which one would fit best. The most logical choice would appear to be the Product Owner.

Another option is the Scrum Master. But a coaching role is a far cry from managing projects. A Project Manager needs to drive the project towards success, a Scrum Master needs to help the team to get the best out of them as self-organising teams in a Scrum environment.

A surprising fit exists as a member of the Development Team. To create a product you don’t only need people that build stuff. Some teams may be well served with someone who can bring in their planning and change management skills.

Whatever choice the Project Manager makes, it comes with a shift of thinking from project delivery to product development.

Do you want to write for Serious Scrum or seriously discuss Scrum?

Thank you for your valuable input Maarten Dalmijn, Leise Passer Jensen, Harry S Long, Matt DiBerardino, Umar

Source link