How to use Story Points, if the team is constantly changing?

What problem do you want to address by adopting story points? Did you share the root cause with the developers and ask them for help?

It is rather hard to advise something without more context, however, I would look into how do you define what your product is, what your goals are, what directs current teams structure, etc.

Ideally, it would be great to share with the developers as clearly as possible what you are striving for, what are boundaries within you are trying to organize things (i.e team should be cross-functional and as independent as possible), and ask them to form teams on their own.

IMHO the trick is that Scrum does not touch organization (company) context, at least not explicitly, and you need to find on your own what needs to change in your organizational context to support Scrum. Scrum Guide sets some boundaries that you should consider in that regard, i.e. Scrum Team boundaries include:

• a cohesive unit of professionals focused on one objective at a time, the Product Goal.
• cross-functional, meaning the members have all the skills necessary to create value each Sprint.
• self-managing, meaning ST internally decides who does what, when, and how.
• small enough to remain nimble and large enough to complete significant work within a Sprint.
• responsible for all product-related activities from stakeholder collaboration, verification, maintenance, operation, experimentation, research and development, and anything else that might be required.

If you (try to) do Scrum, then you should expect that:

Scrum wraps around existing practices or renders them unnecessary.

Scrum makes visible the relative efficacy of current management, environment, and work techniques, so that improvements can be made.

In my own words, some of your impediments are:

• a limited pool of talents
• lack of cohesive teams
• probably a lot of context-switching

However, I doubt that story points helps you with that, so I assume that you are trying to resolve something else?

perhaps we should rethink our business model so there won't be as many team changes as we have now?

Who is actually making these decisions regarding team change?

I've never found sizing to be useful. However, management requires it to measure velocity and to track progress and productivity. When I've had a choice, I've not used sizing. All I need to know is how many items can the developers fit into a one week sprint.

I would recommend thinking about your current model and why you have so many changes to the team composition.

Ignoring story points for a moment, changing the composition of a team changes the team dynamics. Over time, people learn about each other's preferences for communication style, habits, strengths, and weaknesses. Whenever you make any changes to a team, the team needs to relearn this and adjust the way they interact with each other. There's almost always an immediate negative effect on team performance when there are changes, but the changes could result in a better team in the long run.

Looking specifically at story points, they are a relative measure. The value of a story point often changes as the team learns more about the problem domain and comes to a shared understanding of what the different values mean. They are also reflective of the team's Definition of Done and way of working. By changing the team composition, you're influencing many factors that go into a story point. However, even if you aren't using story points, such frequent changes to team composition will lead to questions about any attempts to estimate the team's capacity for work.

Once you stabilize your teams, look to see what problems you have and focus on solutions to them. Story points are a tool, and you shouldn't take a tool to go out looking for a problem to solve.

As you see, our company's situation is extremely dynamic, and there is a new team all the time. 

Story points are not the problem here.

Teams which can't get past "storming" can't deliver reliably.

Implement story points then use them to show how ineffective constantly changing the team makes the whole organisation.

[1] The story points are recalculated during the sprint planning. So story points are not a issue here.

[2] With in sprint swapping the development team staff is not a good idea. 

[3] Here is the main root cause is the team composition. So first address that. Try to organize the teams with mixed skills. Create a plan to bring the team staff to level they come to support the team by arranging internal trainings, knowledge transfer, external training. If required you need to hire few missing staff with specific skills. We also need to consider the agile and scrum is about T shape skills in development team(s). 

Thank you for all your answers, I see many improvement points, and I appreciate it. 

What problem do you want to address by adopting story points? Did you share the root cause with the developers and ask them for help?

The problem we are trying to address is: Today, we can't measure how many User Stories were shipped to production, and as a consequence, we can't forecast how much work is missing for the next release. The situation creates a foggy curtain for the PO, who is unsure when the release date will be and if there will be enough budget to accomplish his/her goals. I'm trying to open this curtain and bring transparency to what was delivered, how much is missing to finish this release, and if we are on a budget. If we face problems, we can play with the scope/timeline/budget and adapt the release accordingly. 

Today we estimate all user stories in hours, so we can have an accurate measure of how the client used much budget and how much budget is still available. Here is an example: https://docs.google.com/spreadsheets/d/1f73YcLmKDIjhU_kGLD5awJ3dSR44IHD…

In the example, we've used 42% of the budget, but I don't know how the % of Scope delivered/missing, and I thought that Story Points could help measure Scope. 

The problem is that the 'Hours Burned' (column F) are all hours used in that week (or Sprint). They are not hours passed on the "DoD," as in Scrum: we only burn story points when they pass the DoD, so it's possible to measure Delivered Scope X Missing Scope. 

Do you see another way I could measure Scope?

Who is actually making these decisions regarding team change?

The CEO of the company: He takes the best developers out of some projects to participate in pre-sales, win new deals, and then stay there to jumpstart the project and after leaves to win another deal. Usually, he plans 1 senior developer per project, but when there is a new senior dev in the company, he adds 2 seniors to jumpstart and later take 1 out. Same for FE, BE, and QA. 

My main goal is to have a healthy negotiation with our clients about scope/time/budget and adapt one of them accordingly, but for that, I need information from the Scrum team about how much is missing for the next release.

Thank you again for your support and attention to my challenge (that might be others' challenge here). This group is fantastic!

> Who is actually making these decisions regarding team change?

The CEO of the company

That sounds rather command-and-control. It's difficult to see how Scrum outcomes can be leveraged when teams are not self-managing. The Scrum Guide says:

Scrum Teams are cross-functional, meaning the members have all the skills necessary to create value each Sprint. They are also self-managing, meaning they internally decide who does what, when, and how.

Thanks for the info, Ian.

Do you mean that the decision of team formation should be in the hands of the developers instead?

Any feedback on how I can update the burndown chart I shared in the previous message to also measure how much scope was delivered?

Kind regards. 

I suggest that you, your Product Owners, your CEO, your individual contributors read the Evidence Based Management Guide (https://www.scrum.org/resources/evidence-based-management).  I also suggest reading Actionable Agile Metrics for Predictability and When Will it Be Done by Daniel Vacati (https://actionableagile.com/resources/publications/) They will provide you all with a new ways of viewing the work that is done and how to measure it's impact. Facilitate discussions on how to change your organization's processes.  In effect hold a retrospective on the past 6 months of your companies work/performance to identify opportunities to improve.  You have already identified a couple in your comments here.  For example

Today, we can't measure how many User Stories were shipped to production, and as a consequence, we can't forecast how much work is missing for the next release. 

Retrospect on that statement with your leadership and the individual contributors that are doing the work.  Find experiments that everyone are willing to attempt.  Notice I said "experiments" and not "solutions".  You will not know if a change is a solution until you try.  There is more to being an agile company than just having your developers do sprints.  In order for a company to be agile they have to be willing to live empirically. If you do nothing to improve you never will.  To me empiricism is a constant process of doing something, inspecting the results, learn from the experience, adapt if needed.  Take a cue from the medical profession.  Have you ever noticed that physicians constantly practice medicine? That is because there is constant learning that changes the way they work.  Same exists in technology.  We will never "get it right" because conditions are constantly changing.  

If we face problems, we can play with the scope/timeline/budget and adapt the release accordingly. 

 

You should be able to release everything that is done, at the end of every sprint (or perhaps more frequently).

You can adjust priority.

You can adjust roadmap.

scope? "in scope is everything which was delivered before we said stop work."