Skip to main content

Due to the Russian invasion of Ukraine, we have paused all purchases and training in and from Russia.

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

Last post 02:28 am February 19, 2021 by Garrie Irons
11 replies
05:38 pm February 15, 2021

Hello,

 

Currently, we are not using story points (so we can't use its advantages) because the team is constantly changing, for instance:

FE = frontend developer

BE = backend developer

QA = quality assurance 

  1. Team A starts with FE1, BE1, BE2 & QA1
  2. 2 weeks after the projects start, BE2 needs to go to Team B because he is a senior, and Team B needs senior support there for 3 weeks
  3. Team A stays without BE2 for 3 weeks
  4. Team B tells Team A they need BE2 for more than 3 weeks, Team A can't do anything
  5. After 3 weeks, Team B delivers BE2 back to Team A, but at the same time, FE1 goes out from Team A and goes to Team C that has an urgent issue. 
  6. Team A gets a junior FE2 to replace FE1, who was a mid developer

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

Developers claim that Story Points can only be used if the same team works together for more than 3-4 weeks, so the whole company gave up on using story points. 

 

Do you think we should use story points anyway, or perhaps we should rethink our business model so there won't be as many team changes as we have now?

 

Thanks in advance!


06:42 pm February 15, 2021

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?


07:52 pm February 15, 2021

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?


09:01 pm February 15, 2021

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.


09:25 pm February 15, 2021

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.


03:15 am February 16, 2021

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.


12:31 am February 17, 2021

[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). 


06:43 am February 17, 2021

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!

 


07:31 am February 17, 2021

> 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.


04:01 pm February 17, 2021

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. 


06:19 pm February 18, 2021

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.  


02:28 am February 19, 2021

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."