Should a technical person take part of the user stories prioritization process?

Question

As a Tech Lead within a "Scrum" team, I am annoying regarding some laid rules.

It is established that only Product Owner, Business Analyst and Scrum Master (and eventually Product Manager) take part of the user stories prioritization process (backlog prioritization).

They are sorting US based on story points, without any further software-oriented facts and knowledge.
Worth noting that those story points emerged from a quick and probably "blind" macro-estimation process, not a deep one.

They judge which valuable US could be delivered and when through those macro-estimations.

I notice that their decision is often based on wrong assumptions and false hypothesis; leading to a sorting readjustment, therefore wasting anybody's time.

Do you consider a Tech Lead (or any other qualified developer) should be part of this prioritization process to aid to prioritize based on programming knowledge?
Like a guarantor of feasibility.

Answer 1

Product Owner and the Development Team collaborate

The Scrum Guide is very clear on these aspects:

1. Product Owner and the Development Team collaborate on Backlog refinement:

Product Backlog refinement is the act of adding detail, estimates, and order to items in the Product Backlog. This is an ongoing process in which the Product Owner and the Development Team collaborate on the details of Product Backlog items.

2. Product Owner's decision is final on ordering the items. However, dev team gets an opportunity to present their point of view.

Product Backlog management includes... Ordering the items in the Product Backlog to best achieve goals and missions; ...those wanting to change a Product Backlog item’s priority must address the Product Owner.

3. Dev team's decision is final on estimate. However, Product Owner gets an opportunity to present their point of view.

The Development Team is responsible for all estimates. The Product Owner may influence the Development Team by helping it understand and select trade-offs, but the people who will perform the work make the final estimate.

However, the Scrum Guide is silent on technical debt. There is no mention of technical debt or anything remotely like it in the Scrum Guide. When the dev team strongly feels that a technical debt needs to be prioritized, otherwise there will be bigger problems down the road ("A stitch in time saves nine"), they are powerless to get that prioritized. If the PO refuses to give enough attention to the views of the dev team on this aspect, I advise my dev teams to include the technical debt in their estimation of related features.

So the answer to your question:

Do you consider a Tech Lead (or any other qualified developer) should be part of this prioritization process...

is YES, you have a right to participate. The Scrum Guide says so.

Answer 2

It sounds like there's a whole lot going wrong with your Scrum process.

It's important to realize that a product backlog is not prioritized. It is ordered. There is no reference to a prioritized or priority-ordered Product Backlog anywhere in the Scrum Guide. In the section of the Scrum Guide about a Product Owner, it's implied that individual Product Backlog Items have a priority. However, the required attributes of a Product Backlog Item are a description, order, estimate, and value.

The Product Owner is the person responsible for managing the Product Backlog. Two of the Product Backlog management activities are "ordering the items in the Product Backlog to best achieve goals and missions" and "optimizing the value of the work the Development Team performs". Simply ordering the work based on priority to someone is not likely to put the items in the order that can accomplish these two activities.

The act of refining (or grooming) the Product Backlog is a collaboration between the Product Owner and the Development Team. This is a time for the Product Owner to explain the intentions behind the Product Backlog Items to the Development Team and review and revise them. This is also a good opportunity for the Development Team to highlight technical dependencies between Product Backlog Items. The discussions during refinement activities should inform the Product Owner to be able to make better decisions when ordering the backlog.

Based on the description of the process, I also have other concerns.

There appear to be three product-related roles mentioned - Product Owner, Business Analyst, and Product Manager. It's important that there is one Product Owner for the Product Backlog. It's OK for this person to have a team backing them up. In a scaled environment with multiple teams working on a single Product Backlog, you may also want to embed someone on each team. But no matter what, there is one person with the role of Product Owner as described in Scrum.

The Scrum Master also appears heavily involved in doing work. The Scrum Master is a coach. You don't say what their role is in managing the Product Backlog, but that they are allowing the Product Backlog to be ordered without input from the development team, they are not establishing and teaching good refinement or grooming activities that is inclusive of the whole team, and they are not teaching the Product Owner about optimizing for value and achieving goals is problematic.

There are also potential pitfalls around having a lead position on a Scrum Team, but these can generally be overcome by keeping the whole team involved at the right point in time and can be valuable to long-term success of a team.

Answer 3

Both previous answers from Thomas and Ashok are right on point (+1!) and I just wanted to throw a slightly different perspective not to the answer itself, but to the question.

Should a technical person take part of the user stories prioritization process?

It is established that only Product Owner, Business Analyst and Scrum Master (and eventually Product Manager) take part of the user stories prioritization process (backlog prioritization).

Sometimes, people tends to get stuck to methodologies, guidelines, rules... and when it happens, I suggest to take a step back and ask again why methodologies exist. Well... they are not the goal, they are the path to a given goal.

Now, thinking about goals, what's the goal of the backlog prioritization? To deliver as much value as possible, optimising time and capacity. That's (potentially) applicable if the team is a Scrum, a "Scrum", an Agile, a "Fragile" or a completely chaotic team... they all want to deliver.

With that in mind, can one justify that a presence of a technical people could help to achieve the goal? If your answer is "yes", you won't need to justify that a technical people needs to attend "because Scrum says so". Depending on the environment you work, there might be more or less resistance to jargons like Scrum, but I doubt no one would be against a proposal that could add value to the team.