We are a small software company with 1 product.

We use scrum.

Our developers choose the features they want to include in each sprint.

  Unfortunately over the past 18 month period, the team haven't once delivered the features they committed to for a sprint.

I've read a lot of posts/answers stating something along the lines of "software is done when its done, no sooner, no later... it does not help to put pressure on the team, to put more people on it, ..." I've received a similar feedback from one of the developers upon my question how we can improve the success rate of sprints. Oh, and yes we do use retrospects.

My question is basically:

When is it fair to look for the problem in the quality of the developers?

I'm starting to think that if you get to choose your own work/features and still fail each sprint either:

• you are not able to oversee the complexity of your own code;
• or the code is so complex that no one can oversee the complexity.

Am I missing something?

We are a small software company with one product.

We use scrum, and our developers choose the features they want to include in each sprint. Unfortunately over the past 18 month period, the team haven't once delivered the features they committed to for a sprint.

I've read a lot of posts/answers stating something along the lines of "software is done when it's done, no sooner, no later... it does not help to put pressure on the team, to put more people on it, ..." I've received similar feedback from one of the developers upon my question how we can improve the success rate of sprints. Oh, and yes we do use retrospectives.

My question is basically:

When is it fair to look for the problem in the quality of the developers?

I'm starting to think that if you get to choose your own work/features and still fail each sprint either:

• You are not able to oversee the complexity of your own code;
• or the code is so complex that no one can oversee the complexity.

Am I missing something?

We are a small software company with 1 product. We use scrum. Our developers choose the features they want to include in each sprint. Unfortunately over the past 18 month period, the team did not once deliver the features they committed to for a sprint.

I've read a lot of posts/answers stating something along the lines of "software is done when its done, no sooner, no later... it does not help to put pressure on the team, to put more people on it, ..." I've received a similar feedback from one of the developers upon my question how we can improve the success rate of sprints. Oh, and yes we do use retrospects.

My question is basically: when is it fair to look for the problem in the quality of the developers? I'm starting to think that if you get to choose your own work/features and still fail each sprint either:

• you are not able to oversee the complexity of your own code;
• or the code is so complex that no one can oversee the complexity. Am I missing something?

We are a small software company with 1 product. 

We use scrum. 

Our developers choose the features they want to include in each sprint. 

Unfortunately over the past 18 month period, the team haven't once delivered the features they committed to for a sprint.

I've read a lot of posts/answers stating something along the lines of "software is done when its done, no sooner, no later... it does not help to put pressure on the team, to put more people on it, ..." I've received a similar feedback from one of the developers upon my question how we can improve the success rate of sprints. Oh, and yes we do use retrospects.

My question is basically:

When is it fair to look for the problem in the quality of the developers? 

I'm starting to think that if you get to choose your own work/features and still fail each sprint either:

• you are not able to oversee the complexity of your own code;
• or the code is so complex that no one can oversee the complexity.

Am I missing something?