Estimates and Priorities: Which Comes First

When developing a release plan, product owners often want to factor cost (or estimates) into where items go into the backlog. For example, you might hear "Do that soon, unless it's really hard." If this happens once in a while it's a useful way to have a conversation about a feature. If this approach is the norm and nothing gets prioritized until the team estimates it. I'd argue that the default order of operations is that features should get prioritized before anyone spends any effort on estimation. My reasons for this are both philosophical and practical.

The philosophical reason is that the Product Owner should be the one to prioritize work. By asking for the estimate first, the product owner is deferring their authority to the engineering team. This creates a risk that the team may not end up working effectively.

The practical reasons for prioritizing before estimating are:

• Estimation takes time, and if you don't start with a prioritized list to estimate with, you spend a lot of time estimating items that may never be worked on. (And yes, you may need to re-estimate items when  they hit the top of the list, as estimates may change based on experience, staffing and architecture.)
• If you estimate as work appears, you lose some of the benefits of fixed, time-boxed sprints, and you increase the overhead cost of planning. 
• By allowing the team to estimate first, and pushing an item off the list because it is too expensive, you are missing an opportunity for a conversation about how best to meet the business need.

Often the first version of a story may seem large because it includes more functionality than needed. If the the team knows that there is a critical feature to implement in a sprint, but that there isn't time to complete it, there may be a simpler, less costly, version of the feature that meets most of the business needs. If the product owner simply let's a large estimate defer the item, then the conversation will never happen and the business needs may not be met, which would be bad for everyone. Likewise if the expensive feature is lower on the list, then you need not have the conversation until later.

This balancing act between estimates and priorities underscores a key principle of agile planning: User Stories are an invitation to a conversation.  By prioritizing first, you can understand where to focus energy on analysis and design. You also keep the agile team focused on delivering business value by placing priority first, and having the engineering team and the product owners communicating actively.