Should we add more items to sprint backlog if there is items that are not completed

Question

Question:

Should we add more items in a sprint if there is items that are not completed but a developer is open.

Scenario:

Lets say we the development team are made up of 5 team members and we have the following sprint backlog with an average velocity of 29SP and we are currently halfway in a 2 week sprint:

Sprint Backlog
 - Login         8SP     State: In Development
 - Add User      12SP    State: Code Review
 - Update User   3SP     State: Done
 - Remove User   5SP     State: In Development

Product Backlog
 - Save User     2SP     State: Ready
 - ...More Stories...

Story 3 was just completed and team is still busy with the rest of the stories should we rather:

1. Swarm/Buddy Program to finish up sprint (I prefer) or
2. Can we add another story (Small Story e.g 2SP) for the open developer because all of the other team members are busy with an item

As stated in this question I know you can add items to a sprint "Yes, you can add stories to a running sprint..." if it dos not affect the sprint goal (scrum.org) post

My opinion is to use methods such as XP, Buddy Programming or Swarming to finish the sprint commitment (if they have finished all the items on their plate they can certainly pull in more work as the team deems OK) and if there is time left, they may add another item to sprint backlog.

What is your opinion and how did you deal with this?

(I know what I should do as well is bring this up in retro to understand why did "under commit" or why is the stories over sized etc.)

Answer 1

I've worked with teams where this is the norm. That said, we tend to fall back on the Scrum Guide for how to handle this. The team is ultimately responsible for organizing and managing their own work with a Scrum Master there to guide them on choosing the best path forward. While it's the job of the Scrum Master to suss out the options available to the team, empowerment of choice tends to engage the creativity within the team and individuals.

I tend to shy away from using always and never, but in cases like this I always let the team decide their best path forward so long as enough options have been considered prior to making a choice. Whether the forecast is met or not, it goes a long way in aiding the psychology of the team responsible for their own work.

Answer 2

Experiment.

Agile is all about experimentation and continuous improvement - discuss with the team, try both, compare results. Rinse and repeat.

With that said, you can stick to agile techniques that are proven to be effective in the long term such as pair programming (as you suggested), mob programming, or backlog refinement.

If your team is less mature or is still grasping to get into agile, the team may decide to add an item to the sprint and keep working, which is fine. However, as Scrum Master, you should raise these scenarios as opportunities for improvement and discover new techniques.