Should the Product Owner prioritize the backlog side-by-side with the customer?
Must this step be done during the Sprint Planning Meeting, or could it be done before the meeting?
Is the meeting restricted only to the Product Owner and the Team?
Add a comment
|
4 Answers
There are plenty of ways to prioritise the backlog.
Firstly, the customer is not always the product owner - the product owner might be representing a number of stakeholders including multiple customers, or people with a longer term view. The product owner really needs to understand all needs and come up with the best way of prioritising.
So then, first and foremost the first rule should be: do what is most important/highest impact first. In real terms as there is always too much work to do, I ask the golden question "does this really need to happen or can it wait". Make sure there is a real objective to every requirement - don't get fooled into thinking something is important unless it can be justified.
The next thing is to think about risk - make sure you have a balanced portfolio of items - things you know are low risk and therefore are going to be done plus a few high risk items (which are probably some of the most important) that you want to get done. Do not have a release full of high risk items for obvious reasons (risk being defined as things which include unknowns/technical or logistical challenges).
Finally, you can do things like quantify the value or impact of work. There are some good books on Agile Estimating and Planning - see Part 3 of Mike Cohn's book on planning for desirability http://www.mountaingoatsoftware.com/books/1-agile-estimating-and-planning
There is no single universal way of prioritizing backlog. Much depends on the way team works and on the customer, e.g. how often they change requirements.
Generally the closer you follow standard (by-the-book) model, the closer you will be to the following solution:
High-level prioritization on coarse-grained features is done at the beginning of the project. It is often done when discussing with the customer which features are must-haves and which are nice-to-haves. It should be done with customer if possible. Otherwise you'd be guessing what is really important and what isn't.
Then before every sprint remaining backlog should be prioritized on fine-grain level. It doesn't really matter whether PO makes it just before the sprint or during the previous one. The important thing is that the team should know their priorities for the next iteration. Ideally this prioritization is done with the customer but when general plan is approved by the customer and it doesn't change much Product Owner can make their own calls basing on their knowledge.
If you work in environment where requirements are changing very rapidly you may consider constant re-prioritization which is basically what happens when you deal with Kanban backlog. In this case PO prioritizes features every time when anything changes.
answered Feb 16, 2011 at 14:29
-
thanks pawelbrodzinski, so as I understand, at fine-grained level the backlog contains both customer requests and internal ones (something to be refactored for example) and the PO prioritizes them according to customer expectations but also considering development opportunity, needs. Feb 16, 2011 at 14:36
-
Depends on a specific approach, but generally yes, you can put in the backlog both features for customer and things you want to do for internal reasons. Feb 20, 2011 at 19:15
The Product Owner and the Customer should be the same person. The project manager should be the person going through the detail, working out resource allocation and tracking progress (using whatever tools are available). The Product Owner is the person responsible for a.) describing at a high level what the requirements are, and b.) prioritising the list of features that come of the list of requirements.
Typically a list of features (/requirements) is scoped at a high-level by the team, which gives everyone a view of how expensive (in time / $$$) any given feature is. This is essential if the PO is to prioritise development (if something is very costly to develop it may be pushed down the priority list).
As features reach the top of the priority list they are broken down into more and more detail, until by the time a sprint starts each feature is described and estimated at a task level by the person responsible for its delivery (i.e. a developer, and not a project manager).
We use Fogbugz, and go through a process of breaking Features down into tasks which are then estimated. The backlog is then prioritised by Feature (not task), and the estimate for any Feature is the sum of all the child task estimates.
Prioritisation should be a continuous process, although it helps if the focus of the team isn't shifted within any given iteration.
-
There's something in your process that I don't understand. You say Custoemr / PO writes down the high level requirement (user story?), then the team makes an estimate and the PO takes the estimate into account to prioritize the features. Then the Team looks at the top ones detail them into tasks and each task is estimated by the team. But how accurate may be the initial estimate without breaking down the high level requirement into task? And if different estimates come out from the tasks estimates should the PO reconsider the prioritization? How much time is spent in this process? Feb 18, 2011 at 8:53
-
The high-level estimate will never match the task-level estimate - it's just not possible to understand how a feature will work until you get into the detail. So my advice is not to bother trying to correlate them. The feature / story level estimate is mainly useful as a guide to the PO for him/her to understand whether something is difficult / hard to achieve. It's relative - "this feature is harder than that feature" etc. Feb 20, 2011 at 16:37
-
The other (possibly controversial) thing worth pointing out is that no amount of estimation, planning or project management will change the actual time taken to implement a feature. This is absolute, and dependent solely on the ability of the developer responsible for doing the work. The PM's role in an agile team should be to ensure that developers know what they should be doing, and then to remove anything that prevents them from doing it. In a productive team the PM is a supporting role, not the primary role. Feb 20, 2011 at 16:42
The product owner should represent the customer and their best interests. If you have the customer on your team too, great! Remember that the product owner is supposed to guide the project into the direction that most benefits the customer, while balancing corporate interests (limited resources, time, etc.)
This should ideally be done sufficiently before the sprint planning meeting so that the team can take the highest-priority stories and start working. From this perspective, sprint planning is only for the team to choose how to fit as many of the top-priority stories they can into the sprint, in the priority order.
The other two answers (@pawelbrodzinski, @Hugo Rodger-Brown) represent two other approaches -- splitting off at a coarse-grained level, and splitting off by feature. Whatever works for your team is what you should do. (I disagree with prioritizing by feature, since you often want "just enough" of more than one feature done within a single sprint.)
