Refinement - Sizing stories

If a developer is working on a feature and more stories are added throughout time and are brought into refinement to size.. Should we have the entire team size the story or just the one developer and tester who is already working on that feature and will more than likely work on the remaining storeies?

@Molly Brewer, The concept of everyone being there to size/estimate the Product Backlog Item (PBI) is so that there is consensus among all the members of the Development Team so that anyone may be in a position to take up that work in the future and it also helps to make the work transparent to everyone. During backlog refinement no one is assigned work for future Sprints. This is because planning too far in advance maybe wasteful. For example, Let's assume you did assign someone to work on a PBI for a future Sprint, however, when the Sprint started the assigned developer fell sick, or quit the company or whatever reason life may throw at you. What would you do in such a situation? The idea is to use Sprint Planning to plan just in time, and during that event having an estimate for the PBI's helps the Development Team to select work it thinks it can accomplish for that Sprint.

Hope this helps.

The Scrum Guide says:

"Individual Development Team members may have specialized skills and areas of focus, but accountability belongs to the Development Team as a whole."

In your team's situation, what would be the best way of ensuring that members are jointly accountable for estimates?

If either would get hit by a bus (and a do not hope so), what would be the impact on the team and the ability to estimate?

I'm not convinced that teams should optimize their processes for events that could be very unlikely. Current health crisis aside, and depending somewhat on various factors specific to location, the dynamics of the organization, and the members of the team, it might be an acceptably low risk that someone is suddenly unable to work.

But I see a common symptom of Scrum-in-name-only, and it might be extremely beneficial for the team to investigate this. Even asking questions around it might expose certain attitudes, assumptions, and behaviours that are unhelpful to the team or organization.

I suggest you question whether you're really getting the benefits of a team, if a feature is worked on exclusively by one developer. Does this feature relate to the Sprint Goal? If so, are the whole team focused on the same goal?

If it's not related to the goal, was there a good reason for that developer to be working on it, and is it still acceptable to the Development Team for further effort being spent in that area?

Are the entire team held accountable for achieving the Sprint Goal, and are the team members in a position to self-organize, to maximize their chances of success?

Does anyone in the organization care about the outcome (measuring the effect of what is done) rather than the output (just measuring what is done)? If so, do the team get that kind of feedback, and would the involvement of more developers allow the team to plan work more effectively, to achieve better outcomes?