Scrum and Project Governance

As a developer I’ve been happy with scrum, but as I’ve been more involved in project management I’ve felt that there is something missing. When I talked to two of our most experienced project managers at KentorSusanne Ribbing and Cecilia Andersson I realized that what I was missing was project governance.

Looking thoroughly, it is enough with a single sentence description of a scrum project to identify the need for project governance.

Throughout a number of sprints the team focuses on the most prioritized items from the product backlog to reach the project’s goals

I’ve highlighted a number of terms that are very much treated as predefined constants by the scrum methodology. I think that’s right, because scrum focuses on the developers. Still, those terms need to be defined and that’s what project governance do.

Number of Sprints

The number and length of sprints in a project is dependent on the project’s deadline, the amount of work to be done and the size of the team. To be able to define those, the goals for the project has to defined, the budget has to be set, deadlines for deliveries listed and the available people for the project known .

The goals, budget and deadline should be part of the project definition, which is the first thing produced by the project governance process.

The Team

Having the right team members is a key success factor to any software project including scrum projects. When the project is defined the competence requirements of the team have to be listed. According to scrum the team should be fully cross competence, with anyone in the team able to take on any task in the project.

In reality, that is hardly ever the case and trade-offs must be done. That makes the task of forming the team even more challenging and important. Among all less-than-perfect options, the correct trade-offs have to be done to form the best team possible.

Scrum itself assumes that there already is a team. To acquire the right resources before the project starts is one of the tasks of the project governance. In a busy organization it is important that the project sponsor has enough powers in the organization to ensure availability of key personnel.

The Product Backlog

The product backlog is the requirements specification in a scrum project. It is formed by finding all user stories required to fulfil the project’s goals. I’ll get back to requirements in the next post in this series.

The Project’s Goals

The project’s goals is the reason the project is even started in the first place. Without defined goals, it isn’t a project (although there are many “projects” out there that lack even the basic goal definition).

The goals of the project is the key part of the project definition, which is defined and decided upon within the project governance structure.

Project Governance as the Outer Feedback Loop

A scrum project is iterative, with each sprint being a full turn of the loop.

The project governance is an outer feedback loop, surrounding the scrum loop and providing the boundaries of the scrum project. All the parameters that are taken as predefined constants in the scrum methodology must be set by the project governance process.

Project Organization

With the role of project governance defined it is time to look into the project organization. Scrum in itself has a very flat organization, it’s essentially a team of peers with the scrum master being the spokesperson.

Note the wording spokesperson. The scrum master is not the manager of the team. The scrum master is the team’s representative.

Project Governance Organization

With the scrum master as the team’s spokesperson there should be someone to talk to. That someone is the project manager. The project manager reports to the steering committee.

The steering committee is the core of the project governance process. It consists of the project’s sponsor and other stakeholders. The project manager participates in the steering committee meetings. Project governance models focus on how the large picture of the project is defined. The details of how the goals are reached are deferred to the project manager. That’s where scrum takes over and supplies a model to get the maximum productivity from the development team.

Combining Scrum and Project Governance

Scrum alone cannot handle the full complexity of a project. Project Governance alone won’t deliver anything but meeting minutes.

I’ve been in a project focusing on project governance. It was well defined and all plans and meeting minutes where in order. Technically it was a mess and nobody knew what to do when. At the end we delivered, but the project was very close to complete failure.

I’ve been in a project focusing on scrum. As a developer it was great, but the project failed to meet the goals, failed to keep the budget and failed to meet the deadline.

A successful project requires both project governance and project management. Scrum defines how to do the tactical project management. On top of that a strategic project governance is needed. There exists a number of different project governance models. The restrictions they set on the project management are different, which means that some models fit rather well with scrum and some don’t. If the project steering model (which is usually dictated by some policy) does not allow an agile process, then maybe scrum isn’t right for that project.

As a Developer, Why Should I Care?

I’m a developer too. I prefer to not have to care about project governance, budget, funding and the political issues of a project. I prefer to keep my focus on the development team and ensure that we deliver high quality software.

When project governance works I don’t have to care. I can spend my days coding with the team. The problem is when project governance fails. Failing project governance results in constantly changing requirements, short-sightedness and unrealistic expectations.

As developers I think that it is important that we recognize the signs of failing project governance as it will make the project as a whole fail. Then the blame game starts. The rules of the blame game are simple.

The last one to see the blame game coming loses.

I prefer not being the last one.

This post is part of the Scrum series.<< Scrum – Nowhere to HideRequirements in Scrum >>


  1. Agree with you that Scrum lack some dimensions, and there’s a reason why alternative ways of managing projects arise. Often it is better to have a clearer separation of roles. A good example of that is DAD, Disciplined Agile Delivery:, a mixture of RUP, XP, SCRUM…

    In projects that I have been involved at Kentor we never run orthodox projects, but rather using best practices and common sense. As a Project Manager I’m striving for keeping things simple. I think the Kentor Business Solution way is a mixture of PPS(Praktisk Projekt Styrning) and a little bit of SCRUM and being a little bit pragmatic makes the day.

  2. What shall we as developer do when-
    Project manager creates story with incomplete business requirement
    AND QA team finds this as bug in UAT time frame?

    1. You are a team, working together to deliver software so you should of course add the required functionality. But from a scrum perspective I think it should be handled as a new user story to make clear that the original story was implemented as specified.

  3. If Scrum is done right, then most of the Governance, minus the team resource allocation, is the ownership of the Product Owner who needs to be empowered by the organisation to do the governance as the businesses representative on the team.

    1. Mohammed you are spot on correct! Reading this article made me cringe i’m afraid.

  4. I really don’t get what governance mean. Or what are those project governance strategies that are implemented in scrum projects. Is there a best project governance strategies that would be effective for most scrum projects?

Leave a comment

Your email address will not be published. Required fields are marked *

This site uses Akismet to reduce spam. Learn how your comment data is processed.