January 20, 2010

The Role of a Scrum Product Owner (and an Introduction to Scrum)

Introduction to the Introduction


Many of you know that I am currently a student at the University of Washington in The Software Product Management program. Overall the program is very good. My wife and I are both in the program and we chose to move from Columbus Ohio to Seattle Washington to take the course because of its special focus. Its special focus is on the specialized field of Product Management and going further it is focused on Product Management of software products.
However, it is not narrow in scope, as we cover everything from recognizing successful ideas for products, to marketing (lots of marketing), to detailed business cases (one former alumni who holds an MBA said this course is basically a “mini MBA”), to project management and of course extensive detail on requirements. I could write much more about details of the program, and for now we’ll start with one small part of it.
Recently, I was asked to do a presentation on the Product Owner role in the Scrum framework. Based on feedback from the audience the presentation went well. They are all much nicer than me though, so maybe they’re being polite. I’ll count on my fellow opinionated Internet friends to give me an honest assessment. Please do.
So, with this pedantic introduction to a topic that has many other informative and experienced authorities that I stand on the shoulders of, lets get into my first article on The Role of a Scrum Product Owner.

Before we Begin: What’s the deal with Pigs & Chickens?
Before we can discuss Scrum we need to cover the deal with pigs and chickens. If you read much of anything about scrum you’ll start finding references to pigs and chicken. This comes from a little story:
A chicken and a pig are together when the chicken says,“Let’s start a restaurant!”
The pig thinks it over and says,“What would we call this restaurant?”
The chicken says,“Ham n’ Eggs!” The pig says,“No thanks, I’d be committed, but you’d only be involved!”

The lesson is: Since the team is responsible, empower them. The practical matters are only team members estimate their work, and only team members speak in daily scrum meetings.

Introduction to Scrum

There is an official description of Scrum by the authority on scrum at ScrumAlliance.com. It's short and you should read it. You will find that most of the people you talk to that are "using Scrum", practice Scrum differently than the description therein. However, due to these differences I feel it is important to give a very brief introduction to my understanding of some core elements of Scrum before we can effectively talk about the role of the Scrum Product Owner.

People tend to practice Scrum in a multitude of different ways. I find that often they don’t know they are using Scrum in a way that is not “official”, but many are aware of it and you’ll hear them say “We use Scrum but...” Thus we refer to these people as “Scrumbuts”, and you can find many articles referring to Scrumbuts, and I think they are some of the very best articles on Scrum (ignore the condescending ones) and iterative project management in general.

The Sprint

Sprints are short iterations of work performed by the team. Key components are the following:
  • Begins with commitments
  • Ends with deliverables
  • Consistent team
  • Consistent length
  • Short: <1 month
Every sprint must begin with commitments from the team. The team makes a commitment to deliver something of value to the project’s customers at the end of the sprint. At its essence this is what the sprint is all about: The deliverables to the customer.

Here, I define "customer" as the one paying for the project/product. This might be a client for a consulting engagement. For a commercial product this might be the executives sponsoring the project.

The commitment of the team cannot be understated. At the beginning of each sprint a success criteria must be defined and agreed to by the team that is crystal clear. At the end of the sprint all parties need to feel that the success/fail result of the sprint is obvious. At the end of a sprint if there is any doubt, try to define a better success criteria next time.

Consistency

Sprints are used as a basis for estimation. So it is important that they have a consistent length and a consistent team. This way, under normal circumstances the same team will get roughly the same amount of work done each sprint. So resist the temptation to let your sprint linger around an extra day and do whatever you can to keep the team intact. If these things change at some point just be prepared to see results that are not consistent with past results.

Scrum Roles


Scum identifies the following roles: Team, Stakeholder, Product Owner, ScrumMaster.

The Scrum Team is the people doing the work. These are usually mostly developers and QA engineers. The team is central to Scrum. The team is permitted to make their own commitment each sprint and they are to be uninterrupted during the sprint with new tasks.

In Scrum, a Stakeholder is the customer. Usually the one paying for the project or the ones who will use it and decide whether the project’s result is successful or not (this is different than most other project management methodologies such as PMI).

A Product Owner is the person who is responsible for the business value of the project. If you’re working on a product this is usually a “Product Manager”, in some other cases this might be a representative of the client.

The primary responsibility of the ScrumMaster is to remove obstacles for the team. He/she should also make sure that the other roles work according to the scrum framework. He is a "master" of the scrum framework, not the "team". In this respect a ScrumMaster is unlike the role of project manager as he doesn’t have any particular authority over the team. However, many of the skills that a project manager uses is also useful as a ScrumMaster. These include communication, people skills, good judgement, etc. The ScrumMaster is often a member of the team, but can never be the Product Owner too.

Scrum Artifacts

Product Backlog

The product backlog is a prioritized list of business value that the team needs to deliver. It is not a list of tasks. “Business Value” means value to the stakeholders. Everything must be expressed in a way that, when “accomplished”, the stakeholder will experience/see a real benefit.

Sprint Backlog

The sprint backlog is a list of items from the product backlog that the team commits to delivering during the sprint. Additionally, each product backlog item that the team commits to deliver should be decomposed into its respective tasks during the Sprint Planning  meeting.

Burndown Charts

Burndown charts are a measure of the total amount of “effort” (e.g. estimated hours of work) that is remaining during a sprint. By the end of the sprint a sprint burndown chart should show that zero effort is remaining.

Scrum Ceremonies

Sprint Planning Meeting

Before each sprint the team sits down and accomplishes two things:

  1. Commit to delivering a selection of the highest priority items from the product backlog. This selection is made exclusively by the Team and is their commitment.
  2. Decompose the selected product backlog items into manageable tasks.

If you want to learn more about scrum I recommend Scrum training or spending time with a passionate Scrum practitioner (not just any ol’ scrumbut Joe). However, a great book on the topic is Ken Schwaber’s Agile Project Management with Scrum. Check out it’s rating on Amazon and you will see that many others agree.


Daily Scrum

Every day of the scrum the team meets very briefly and every team member concisely shares the following information with the rest of the team:
  • Accomplishments since our last scrum meeting
  • Things I will accomplish before next meeting
  • Obstacles to progress
There should be about three accomplishments and three things to accomplish. The obstacles should be outstanding and the ScrumMaster must take responsibility for either resolving them delegating someone to resolving them. Every team member should state all three points. If he/she has no obstacles they should state that clearly: “No obstacles.”

Sprint Retrospective

This is usually known as a “postmortem” but that term is often considered to morbid. Essentially it is an opportunity for the team to sit down briefly at the end of a sprint and discuss what worked well during the sprint and things they should change for the next sprint.

That’s it!

Principles of Scrum

As you can see Scrum is very simple. However, I like to say that Scrum is simple, but it is not simplistic. For Scrum to be successful you will need at least one person who truly understands and believes in the principals behind it. There are three principals of Scrum:

Transparency
You should have problems when using Scrum ("that's a feature, not a bug").
Inspection
You cannot inspect without transparency.
Adaption
You cannot adapt if you do not inspect.

The process of Scrum is designed to expose problems. You will find things like requirements that users don’t really want, that you began with not enough requirements, unrealistic estimates from dev or QA, unrealistic time constraints from stakeholders, team members that contribute significantly differently from others, lack of commitment from team members, lack of accountability, etc. That's good! Identify those things and discuss how to fix them, and fix them! Remember, it’s only two weeks. So if you can identify some problems in two weeks then at least you identified them in two weeks and now have the opportunity to start fixing them.

If you have genuinely smart/effective/savvy people scrum will work well (but so will just about any other process). Unfortunately, this is rarely the case, and with an experience Scrum coach or ScrumMaster, you will be able to identify and adapt to challenges rapidly.


Now, that this is out of the way, soon we'll talk about the role of the Product Owner in more depth.

Series: This article is part of a series that includes the following articles: The Role of a Scrum Product Owner, Responsibilities of a Product Manager in Scrum, Techniques for a Product Manager in Scrum: User Stories, Techniques for a Product Manager in Scrum: Estimating Techniques.

blog comments powered by Disqus