Skip to content

Posts tagged ‘product owner’

Scrum Role: Scrum Master

The Scrum Master

There are three fundamental roles in Scrum: the Product Owner, the Scrum Master, and the Team.


As an Agile Project Manager, the Scrum Master is the person responsible to ensure the adoption and adherence to the Scrum process. With no formal authority over the Team, the Scrum Master facilitates the various activities and maintains the Burn Down Chart.

What the Scrum Master does

As a liaison between the Product Owner and the Team, the Scrum Master is responsible for the following activities:

  • Helps the team maintain their productivity by removing barriers and preventing interferences;
  • Supports the Product Owner in achieving the project’s goals;
  • Facilitates communication between the Product Owner and the Team;
  • Updates the Burn Down charts and other artifacts to make team progress visible;
  • Organizes and facilitates the key meetings: definition, planning, building, demonstration, and retro-spection.


Scrum Role: Product Owner

The Product Owner

There are three fundamental roles in Scrum: the Product Owner, the Scrum Master, and the team.


The Product Owner is the one person responsible for the project’s success. The Product Owner leads the development effort by conveying his or her vision to the team, outlining, and prioritizing it based on business value. As such, the Product Owner is responsible for representing the interests of everyone with a stake in the resulting project.

The Product Owner differs from that of the traditional Product Manager role in many ways.

What the Product Owner does

As the owner of the product vision, the Product owner shoulders all the responsibility for the project success and is ultimately responsible to the Team, stakeholders and to the company.  Here are some of the activities perform by the Product Owner:

  • Creates and maintains the Product Backlog;
  • Prioritizes and sequences the Product Backlog according to business value or ROI;
  • Assists with the elaboration of Epics, Themes and Features into user stories that are granular enough to be achieved in a single Sprint;
  • Conveys the Vision and Goals at the beginning of every Release and Sprint;
  • Represents the customer, interfaces and engages the customer;
  • Participates in the daily Scrums, Sprint Planning Meetings and Sprint Reviews and Retrospectives;
  • Inspects the product progress at the end of every Sprint and has complete authority to accept or reject the work done;
  • Can change the course of the project at the end of every Sprint;
  • Communicates status externally;
  • Terminates a Sprint if it is determined that a drastic change in direction is required;
  • Understanding and communicating the customer needs;
  • Meeting the project goal and financial targets such as return on investment (ROI);
  • Collaborates with the team and aligns with the stakeholders throughout the entire release.


How I failed as a Product Owner and the lessons I learnt in the process

I failed.

There it is, in writing for the world to see. You might think it is a bad idea to write about a project that failed – especially since I was the product owner. Fair point but I would have to disagree for the following reasons:

  • If we spend time reflecting on the reasons behind our failures, we can learn more than when we succeed. Success leads us to believe we know how to lead a project and that we are a key contributor to the success of the project. What can we learn from success? Failure is a humbling experience and spending time to analyze our decisions allows us to improve our abilities in the long run. So failure isn’t good but failure without retrospection is even worst – unless you are looking to repeat your mistakes.
  • If you want to grow as a person, you need to take some risks. The same logic applies to organizations that want to grow, they will also take some risks. As a consequence, if you want to take risks, you better tolerate failures. As Michael Dell once said, it’s OK to fail as long as you fail quickly and gracefully.
  • Someone else (I don’t remember who it was) said that you judge people’s character not by the number of time they failed but by how quickly to got back up on their feet and went on to tackle another challenge. The point here is not to run away from your failures but not to sob and feel sorry for yourself.

So here’s the short version of my failed project.

About six months ago, I presented to our executive committee the idea of launching a content based web community geared toward Agile software development.  There area already some well known sources of information around agility and some more specific geared toward Scrum but there isn’t a single leading source of information in French (being located in Canada and serving Quebec and France, this is an important need for people we work with). I thought it would be a great way to contribute valuable content to individuals and organizations looking for help in their implementation of agility.

As a true innovator, my boss challenged me to think of the next generation of a web community. Let’s not use what exists today and let’s create a place where people will enjoy gathering – not just a blog or a wiki but something better! So the project began.

After a few weeks, a few of us had brainstormed the new concept, pitched the idea to a few colleagues and went on to do a Sprint 0 (see below for the definition of a Sprint 0). The new concept was a tool that would support collaborative text edition where the community would vote on the best content. Since it is unlikely that we will initiate the same project twice, I might write about some of the project details in an upcoming post. Stay tuned for that.

So a small development team and a Scrum Master were assigned and we started our first sprint of 2 weeks. Than the usual product demo took place followed by the sprint retro. Then another round of sprint planning, execution, demo, and retro. We repeated the process for a few weeks until we realized we weren’t making enough progress. Quality code was being written, must product demos were successful, the team retrospection were informative and the team was increasing its velocity. So why weren’t we getting closer to the goal?

The make a long story short, the concept turned out to be innovative and the development project turned into an R&D project where most of the efforts were spent on the research part. So after 4 months of iterative development, I killed the project!

What I learnt in the process is the following:

  • In an organization where there are many competing priorities, launching a new content based web community is a challenge in itself. Adding to the complexity of the original project by launching an innovative collaborative text editing plate form isn’t a smart idea. It would have been a thrill to hit a home run but getting to first base would have been a better strategy. It might not be as glamorous but it is a safer bet and there is always the opportunity to build incrementally after you get the first version out.
  • Execution is much more difficult than coming up with an idea. Since the idea seemed good and that people agreed with the concept it was easy to believe we could deliver an outstanding product.
  • Every organization is resistant to change, so when a new idea is launched internally it is critical to explain the vision and the benefits to as many people as possible to get their buy-in and identify potential pockets of resistance. It is naive to assume that everyone will see the value of the new concept and will immediately accept it. Once the idea is conceived, promote it as if it was already ready to launch.

It is great to work with an organization that supports entrepreneurship and that invests in its people. Next time around, I will get to first base…


Note: The purpose of a Sprint 0 is to draft a project charter that includes the following elements: vision for the project, objectives, assumptions, success factors, success criteria, roles and responsibilities, priority matrix (scope, time line, and budget), risks, and mitigation. In addition to a project charter, the planning stage allows the project team to start populating the product backlog.