Should you use story points for a team of developers developing multiple systems?
This question was asked by scrum masters who’s teams are not ideal agile teams as the company introduces agile in multiple steps. Their team typically consists of experts focused on web, ledger, back- ends PHP / Java. They are focused either on technology or business domain without knowing a lot about others.
But, in our opinion is the estimation with story points possible even in such teams.
The definition of the velocity includes neither roles nor team structure nor substitution. Many agile teams we worked with apply story points even they are not IT teams.
Velocity in Agile is a sum of completed story points by the team per sprint.
Velocity, however, can be hard to keep consistent in the team full of experts who are not able to substitute each other. The root cause is in most cases in an incorrect way of the estimation.
To deal with that, we suggest to level-up story point size among such team. It is not so hard.
How to align the estimation scale?
Look at your historical backlog items and compare the spent time.
Agree on groups, i.e. SP1 = <0, 1MD>, SP2=<0.75-3MD>.
Groups can be slightly overlapping.
Now, select some reference stories for every subgroup of the team and assign them to the appropriate story points’ reference group.
Once you have them (3-5 is enough, ideally of different issue types), you have the estimation references that you can use.
From that moment, however, forget about the time in the estimation process. Just compare the complexity of the estimated backlog item comparing to groups defined in the steps above.
Of course, later in sprint planning, break backlog items to subtasks which can be estimated with MD.
What else you can do?
The more correct solution is to change the team organization model. Are you sure your teams are properly organized around products or business domains? If they have nothing in common, are they really the proper team? Try to identify value streams in your company, split the product portfolio into these value streams, and identify which team you need to establish for products in value stream programs.
Another option is to help teams build the knowledge to enable substitution capabilities. You can do the capabilities mapping to discover potentials of team members and find who can teach what within the team.