Take the 2-minute tour ×

Regards velocity: how can a team with a mix of skills be allocated time in the next Sprint based on velocity?

Teams have different levels of developer as well as people more skilled in front end and back end development.

Different Sprints have different amounts of pull on each group.

It doesn't seem to make sense to me to simply say 'the team' gets 100 points done per Sprint so then allocate 10 points of back end work and 90 points of front end work to a Sprint when in actual fact its back end people that have a velocity of 90 points and the front end people who have a velocity of 10 points.

I can't imagine that the answer is simply to ignore peoples strengths. Should I split velocity by sub-teams?

share|improve this question
split the user stories in a different way to fit your team. Yes I know it's hard but it will make planning easier. –  Jocke Dec 17 '13 at 20:20

3 Answers 3


The team as a whole comes to a common agreement as to what the number of story points should be for a story. As the same team will be determining these story points for the duration of the project, then the velocity of the team should become more accurate the more sprints they do.

Yes, some developers will be slower than others, but if the team remains constant, then the velocity calculation will get more accurate, allowing you to make a decent estimate on when stories can be delivered.

Splitting the velocity by sub-team will not help you estimate when stories will be delivered, the velocity of the team as a whole is the crucial factor.


A Scrum team should consist of developers (where developers are those in the development team e.g. software engineers, testers, business analysts) who are generalising specialists; Each team member should be capable of doing the back and front end development, and the testing, in fact everything needed to deliver the stories. Yes, in practice some team members will have expert front-end experience (for example), but as the sprints progress there should be knowledge sharing so that all team members are capable of developing the solution (e.g. by pair programming, mentoring, documentation(!)).

A good Scrum master will encourage this sharing of knowledge, and you may/will find that some front-end developers are excellent back-end developers and vice versa!

It is this concept of breaking developers out of their silo'ed environments which companies struggle with, but it's vital for successful Agile/Scrum teams.

share|improve this answer

Velocity is a team measurement, and the numbers are generally meaningless when compared between different teams. The same thing would occur if you were to break it down to an individual level: the velocity of one individual is not comparable to the velocity of another. The concept is only useful when comparing one sprint of the project with another, so changing your measuring metrics mid-project will probably cause you to misinterpret the results.

Are you trying to determine how productive individual people are? You can gauge that other ways, such as asking the other team members if they feel the person is doing a good job, pulling their weight in the team effort, etc.

share|improve this answer

A scrum team is usually of size 7 or 8. In that if there are experts where 2-3 can do backend work well and they are burning 90 story points. Then it is a risk and too much dependency on them. It is better to share knowledge so that everyone in a scrum team is aware of backend as well as front end. In the initial stages you can keep aside 25-30% of the time as rampup and commit less story points say 60. Eventually when the team ramps up, the velocity would make sense. Velocity always means how much the scrum team can accomplish irrespective of individual expertise.

But if you want to keep the back end and front end expertise distinct, 2 separate scrum teams can be formed. Then velocity would make sense

share|improve this answer

Your Answer


