I work in an organization that follows scrum process and we have been struggling to stand up to sprint commitments and are having to stretch our work hours every time to fill this gap, some times even after that we dont deliver what we have committed. Its very frustrating now as this disturbs the work life balance and even then the end user is left dis-satisfied. So I thought of getting some suggestions online to tackle the scenario, I read some links but didn't get concrete answers. So I would describe the scenario below hoping to get back some solution.
first I would like to describe the team structure : We are a team of 7 developers now including one developer who joined the team recently and are working on a project which is running from past 9 years. The team has developers with different experience levels in the project, resulting in not everyone having the same level of exposure to the project and also
Following are the questions being raised by the client side causing several escalations and a huge pressure is building up on the team. So before I counter back I would like to get some perspective on the opinion I hold , please let me know if what I think is the right approach or there could be a better approach :
In the past few sprints the sprint velocity has decreased even though the team size has increased : -> increasing the team size does not guarantee a increase in the velocity, instead it tends to decrease as the new member becomes more of a liability to the team. Also many of agile links I read stated that the team velocity is unknown when the team is new, the project is new or in case new members board the team or old ones leave.So the approach should be to take a few steps back and start with a lower velocity that the team can achieve rather then enforcing them to deliver at the same rate.
Things to consider while sizing a story : ->given that we have team with different level of experience in the project, should we also consider the analysis time taken by the ones who have less exposure to the application, as its possible that for a person who is working in the project from last 5 years things are clear and he might feel that the size should be 5, while for the one with 1 years of experience in the project might spend additional time in analyzing resulting in an increase in the size. Also since every individual gives his own estimate for a story, is it fair to consider the analysis time needed while estimating the size ?
We have a scrum master who is also part of the production support team for the application, which means he is well versed with the application both functionally and technically -> is scrum masters involvement in estimating the size of the story the right approach or its entirely the development teams decision and scrum master has no word to say in this. as we have had cases where our scrum master went down to saying that its his personal opinion that the team gives more size to the story then needed. this kind of involvement by the scrum master is now having an influence in the sizing game and the team is not able to give sizes freely.