Category: product owner

Product Owner vs Product Manager

November 6, 2009 by Jack Milunsky

Introduction

Based on a recent post on yahoo forums, seems like there may still be confusion out there as to what the differences are between these two roles. Questions like, is there overlap? can the Product Manager take on the responsibilities of the Product Owner? what are the specific requirements for either role? pop up all the time.

There was a really good discussion on the Scrum Development Yahoo group on this topic and some really good points were made. So I'll try to distill this for you here and of course put my own twist on this.

When is the story too big?

May 14, 2009 by Peter Stevens

Nothing can ruin a Sprint Review meeting like having no stories to show the product owner when the sprint is finished. This week, I participated in two Sprint Reviews in two different companies. Both teams had the same problem. They took on stories which were so big that they had a queasy feeling committing to them. Of course, the stories grew during the sprint.

When should you advise your team not to accept a story because it is too big?

3 Warning Signs

Not accepting over sized stories is pretty standard advice. But how do you recognize when the story is too big? These are my warning signs:

1. Past performance indicates you won’t get it done
2. The story is large compared to the team capacity for the sprint
3. The demo is complicated and / or demos many sub components.

Contracting for Agile Software Projects, Part 1

April 22, 2009 by Peter Stevens

As a customer or supplier of software services at the beginning of a Software Development Project, you know that there is too much at stake to work with just a verbal agreement. Although the Agile Manifesto values customer collaboration above contracts, contracts are necessary when working with external suppliers. A contract is really just a set of written playing rules. The right rules increase the chance of success for both parties. The wrong rules make cooperation difficult and hinder progress. Which contract forms are best for agile software development projects?

This is the first of two articles. In this article, we’ll look at the purpose and contents of a contract and some criteria for evaluating agile contracts. Next week, we’ll look at contracting alternatives for Scrum software projects and examine their strengths and weaknesses.

Product-Owner: Are you a chicken?

March 2, 2009 by Peter Stevens

One key to success in any development project is the collaboration between the customer and the team. As Product Owner, you are either the customer or the conduit to the customer. Your job is to guide the development effort to a successful conclusion. No one on the team is pulled in more directions at once than you are. You want your team to work effectively. You want your team to build the right product.

You must allocate the right amount of your time between team, customers, management and other duties. Are you spending enough time with the team? How much time is enough? Does the team even want you to be present at their meetings? If not, why not? And what are the implications of not spending enough time with your team? Three suggestions for better collaboration with the team.

Top 10 Activities of the Product Owner

February 20, 2009 by Jack Milunsky

Over the course of the past 5 years, I have often been asked about the role the Product Owner plays in an Agile company. More recently in a rather controversial blog post by Adam Bullied he raised the question – Is there such a thing as an Agile Product Manager?

From my experience, there is. And this role in Scrum is defined as the Product Owner. The Product Owner from my experience differs from that of the traditional Product Manager role in many ways. Additionally, the role the Agile PM plays may vary depending on the environment and situation at hand, but for certain there are key activities the Agile PM must perform.

The Product owner (or Agile PM) shoulders all the responsibility for Project success and is ultimately responsible to the Team, stakeholders and to the company. With so much at stake it's easy to get bogged down or revert back to old ways and the whole team suffers as a result. In order for Scrum to work the Product owner has to focus his time on activities that matter. (read more...)

Why do we have a Product Owner anway?

February 13, 2009 by Jack Milunsky

I can’t stress enough just how important the role of the Product Owner really is. This job is not for the faint-of-heart. In fact, the Product Owner is probably the most important individual on the Scrum team since he single-handedly is responsible for driving the direction the team is taking.

The Product Owner And The Team

The team is responsible for how they are going to implement the functionality. The Product Owner, on the other hand, is responsible for WHAT they are going to build and in what priority order. Although, there are times that Architectural elements will be prioritized ahead of business functionality, for obvious reasons. So, the Product Owner is like the driver on a bus. He can drive the team around in circles, off a cliff or he can ensure the team is taken to a place where it can make a significant impact – Imagine that!

A Simple Scrum Sprint Review

January 21, 2009 by Peter Stevens

At the end of the sprint, the Product Owner, Team and Scrum Master meet to review the progress of the sprint. The product owner has to evaluate the state of the project so s/he can decide what to do next. How does the Product Owner ensure that s/he gets a complete and correct understanding about the state of the project, including all inconvenient truths? Here is a simple agenda/meeting template to follow, to make sure all the bases are covered.

Last week, I introduced that concept of a Sprint Contract to define the parameters of the sprint. The factors Scope, Quality, Time and Cost will be familiar to any project manager. Scope is defined by the stories and in particular their size. Quality is defined primarily by the definition of done. Time is fixed by the sprint duration. An upper limit on the costs is set by the team size * sprint duration, after adjusting for absences and other tasks.

A simple sprint review needs to

1. Confirm that the team has delivered on its commitments
2. Confirm that the overall project is on track
3. Examine the functionality which has been delivered.

My First Experience with Business Value Poker

December 17, 2008 by Peter Stevens

Last week, I wrote down a new idea about how to determine business value using a variation of planning poker. At the same time, I tried out the method in a real project. How did Business Value Poker survive its first encounter with the real world?

Previously, the two product managers had come up with a list of functions. The dilemma was that Product Manager #1, the manufacturer of the complete system, valued new hardware sales generated by the software. P-M #2, a user of the system, valued operational savings. At the first attempt to prioritize, each manager was given 1000 points to distribute among the functions. The business value was the sum of each party’s vote. This produced a value but no consensus.

Figuring out Business Value with Planning Poker

December 10, 2008 by Peter Stevens

In a perfect world, there is one product owner who knows the market, knows the application and can assign business value to each function on the backlog. But coming up with a dollar value for a feature can be difficult and in a joint venture the problem is compounded, because stakeholders with complementary interests may have a very different basis for valuing a function. There are two product owners, so the situation can be very delicate. How can the two parties agree on priorities for the next release?

Prioritizing the Product Backlog

October 8, 2008 by Peter Stevens

Any project plan is a mixture of what the product owner wants and what the team can actually deliver. The product owner naturally wants more than the team can deliver, so s/he has to prioritize in order to get something useful in the desired timeframe.

Once you have a prioritized product backlog, you have the prerequisites for calling the first Sprint Planning Meeting. How do you convert an unordered list of features into a prioritized product backlog which you can give the team to implement? What should you do first?

I'm not sure that there is a correct answer to this question. It will depend on your product, your company and your situation. Let's take a look at some widely used strategies for prioritizing the product backlog

• Minimum Marketable Feature Set - the first pass to narrow the list of stories
• Business Value First - Focus on High Value Functions
• Bang For the Buck - Go for easy wins
• Technical Risk First - Do the hard things first
• Defer Risk - Do the hard things later (or never)
• Vote - Ask your users