PBI priority and tasks

1) ALL the PBI should have priority, not just the one we chose for the Sprint?

Why do you think that work has to be prioritized at all? The Product Owner should order the Product Backlog and this might involve consideration of priority.

->, So each sprint planning meeting the first thing to do is to choose the Objective of the sprint 'product owner'

Why do you think the Sprint Goal is determined by the Product Owner, and why do you think such a one-sided decision would be the first thing to do in Sprint Planning?

and then he prioritizes all the PBI.

If he waited until Sprint Planning before considering such a matter, how likely is it that the work will have been sufficiently refined and made ready?

2) Can a task of PBI be 'searching ' if we don't know what we are going to do?

Wouldn't you expect work to emerge during the Sprint?

Hello,

We do not assign priorities to PBIs. Instead of that we order them.

Why? If a Product Owner (PO) asks stakeholders to assign priorities high, medium or low to PBIs then typically 85% of PBIs get priority high, next 13% get priority medium and the very last one PBI gets priority low. (Believe me or not: it was tested across many organizations of different size and profile, on various projects with different teams - it is always one or max. two PBIs that get priority low. This is natural from stakeholder's point of view - if something is unimportant why should we pay for it at all? The project includes only important items.)

And this is not the information we want to get. Because we cannot do 85% of work during the first Sprint.

So we order PBIs. It is not an easy task. Therefore we have a dedicated accountability, a dedicated person called Product Owner to do the job.

In a perfect world, the PO would talk to stakeholders and obtain estimates of value that completion of each PBI brings to the organization. It does not matter if these estimates of value are in dollars or value points - use whatever works for you and your project. Then the PO talks to the Developers, explains each PBI and gets estimates of effort. Again, a this point it does not really matter if these are in man-hours or story points. Both numbers are estimates only. But it is better to have estimates than nothing.

Having these estimates for each PBI, the PO would divide estimate of value by estimate of effort and create estimate of Return On Investment (ROI). Next step is easy: in Excel, the PO picks 'Sort' option and selects 'ROI' column, from highest to lowest value. PO orders PBIs based on estimated ROI, having items with highest ROI on top of the list. This way we can ensure that maximum value is delivered during Sprint, because we select only PBIs with high or very high value and low effort, i.e. we can select many of high value items for one Sprint.

That would be in a perfect world. But we are living in a real world... So it cannot be that easy.

The PO, when ordering PBIs, must also take into account following factors:

• technical dependencies - if Item B depends on Item A, then we have to build Item A first and then Item B even if Item B represents higher ROI.
• dependencies on other teams - the Scrum Team is cross-functional and has all skills necessary to deliver an Increment but it does not operate in vacuum. The delivered Increment must be installed on some infrastructure and must be supported by support staff. In large organizations, there are dedicated infrastructure and support teams who can influence what is possible and in what order.
• dependency on external providers - very often we integrate our solution with components, services or products of third parties. These could be subject to prolonged procedures of selection, approval and purchase. It is pretty good if selected product and version already exists on the market but sometimes we are expected to integrate with next version with enhanced functionality scheduled to be out next month (aka. vapourware)
• regulatory requirements - sometimes a functionality must be delivered before a deadline otherwise our organization finds itself out of business. Yes, the PO has option to assign extremely high value estimate to such PBI and this is fair.
• internal politics in the organization - this one looks like a bit against Scrum as PO should be guided by value delivered by completed PBI only. But there is also a kind of value in "ensuring acceptance and support for the project within organization". Usually, there are many stakeholders representing different divisions and having different needs and priorities. The PO should balance their expectations, trying to keep all of them happy (or at least not angry). Often, the PO is under constant stress from stakeholders, each of them trying to put their needs first. Sometimes it might be reasonable to be agile, re-order some PBIs and avoid conflicts, ensuring smooth collaboration in the future.
• any other factors the PO considers important

One important remark: there is no PBI readiness on the list above. If a PBI is not ready then it is reflected indirectly, in higher effort estimates provided by the Developers. This is because of two factors:

• the Developers will have to do some analytical work, usually done by the PO. There is nothing wrong with that - the Developers are smart, they can do it. It only means that when estimating effort for a PBI, the Developers must add some story points for that extra work.
• the Developers will add some contingency for the unknown. For example: if a ready and well defined PBI can be estimated at 40 story points, then not ready, not clear and high risk PBI would be estimated as something between 20 and 60 story points, it depends, we are not sure. However the final answer from the Developers would be 50 or 55 story points - they will assume there is a significant "grey area", something could go wrong and it is better to be on a safe side.

As the PO clarifies the PBI, the initial effort estimate could go down.

To summarize:

1. Assigning priorities will not work, is it not precise enough, the PBIs must be ordered, no two PBIs can have equal position on the Product Backlog, this is not allowed.
2. Ordering PBIs is a very hard and complex task. Sometimes it can be even risky (as the PO is exposed on all politics within the organization).

Can 'searching' be a valid PBI? Searching for what?

Anything can be a valid PBI, anything that adds value to the users and has clear completion criteria. If you know what you are searching for, if you know what value adds your search to the users/stakeholders, if you know when your search is done (if you can write Definition of Done for task type 'searching') - then yes, 'searching' in my opinion can be a valid PBI.

Just 'searching' is not a PBI. It is a placeholder. Find something that brings real value to the users - no matter how small - and complete it instead of 'searching'. Scrum is about delivering value, it is not about working hard and long.