What kind of approach would be deemed suitable for a team in which the members change frequently?
In an organization, I worked for, there was frequent intake of new employees (Because there were employees leaving frequently for better pay, benefits etc)
However, we were very much keen on using Scrum. But this obviously wasn't easy as the velocity, capacity and the team dynamics frequently changed. Is there a better approach(Or a tweak within Scrum) that better handles this situation?
There are a number of ways to accommodate team changes in your Sprint Planning. I detail three of them below. Use normed/smoothed/adjusted velocity as a planning value, not a management target. Most importantly, focus on tracking Sprint Goal completion rates (not velocity) as your key performance indicator (KPI).
Change has Impact
Imagine your process as a factory. Every time you retool your factory, and every time you change the flow of your assembly line, quality control and productivity will likely take a short-term hit. Likewise, Scrum is a tool, and the Scrum Team's composition is an essential aspect of its workflows.
Embrace Change; Avoid Unnecessary Change
Agile frameworks embrace change. However, avoiding unnecessary change is a key element to effective process control. Acceptable levels of staff turnover (whatever "acceptable" means to your organization) are necessary, but very high levels of turn-over should be addressed as a strategic issue both within the Scrum Team and within the ranks of senior management.
Velocity is not intended to be a measure of productivity, nor should it ever be used as a management target. Instead, it should ideally be viewed as a trailing metric that helps to forecast near-term capacity.
When used properly, your velocity metrics should smooth out to represent the team's average capacity to do work, while simultaneously accounting for routine perturbations like expected turn-over. The mean or range of your velocity serve as planning values that can then be fine-tuned to provide additional slack when needed.
As an example, let's say that a long-running Development Team of seven people has maintained a velocity range of 45-60 story points per two-week Sprint for the past six months. Over that period of time, three people have come and gone. So, how should you look at this?
Work with the averages.
Since the range of 45-60 holds over time regardless of the changes to team composition, just ignore routine perturbations and focus on achieving the Sprint Goal each Sprint. The raw numbers of completed story points might go up or down for a while, but will smooth out again over time once the team re-norms and trend towards a new planning value that accurately reflects the current makeup of the team.
Apply a fudge factor.
If the data shows that the team does an average of 45-60 story points per two-week Sprint, but only completes 30-45 story points per Sprint for the first six weeks after a team change, you could simply discount your previous velocity by 25-50% during the Sprint Planning session following the change. After a few Sprints, the empirical data will reflect your team's new norm.
Bake in Slack
Scrum is about creating a predictable cadence for incremental delivery. Therefore, being able to say something like:
The team can reliably deliver the Sprint Goal more than 80% of the time when the Sprint Backlog contains no more than 40 story points.
is often more valuable than focusing on the maximum possible throughput or achieving the highest levels of planning accuracy.
If relying on averages or fudge factors doesn't suit your near-term planning strategy, you might try baking in sufficient slack into your planning values to absorb routine swings in capacity while still reliably delivering each Sprint Goal.
Focus on Sprint Goals
Velocity is primarily a capacity planning metric. A Sprint doesn't succeed because the team completed lots of story points. A Sprint only succeeds when it meets the Sprint Goal, whether that goal is a concrete increment or some form of validated learning. That means tracking the percentage of Sprints that successfully delivered the Sprint Goal is a better KPI for your Scrum process than tracking velocity as a wildly-inaccurate proxy for "productivity."
Productivity is really about the ability to deliver potentially-shippable increments of product. Estimating effort rather than observing results is helpful for planning, but entirely the wrong tool for measuring effectiveness. As an empirical control system, Scrum relies on the latter.