A few thoughts on team velocity and value delivery

Will increasing the amount of people on a team accelerate value delivery?

In the short term, increasing resources on a team that has normalized (see the Tuckman ladder model - https://en.wikipedia.org/wiki/Tuckman%27s_stages_of_group_development) will likely decrease its velocity as it takes time for the new person to understand the nature of the work and the culture of team. People learn to work together, to improve together, they build trust, they win together and they lose together. Whenever you change the configuration of a team (by adding or removing people) they will probably take a few steps back into Tuckman’s journey or be caught by Brook's Law. The positive impact to the team may take weeks or even months to be realized. Or worst case, the new addition is a bad fit for the team and either self-selects out or is rejected and you’ve likely caused damage to the team that could take weeks or months to recover from, and perhaps impact the career of the person you moved to the team.

Well then, how can I increase an Agile team’s velocity?

You can increase an Agile team’s velocity by multiplying Story Points by 10. Or if you’d like, add 100 points to each story point estimate. This is a snarky response. You're asking the wrong question. What you should care about is how can I improve the rate that my team delivers value to the end customer. There is no silver bullet on how a team can increase value delivery. Start with evaluating whether you should decrease the cycle time by deploying increments more frequently into production so you minimize feedback response times and cost of delay. There is no better measure of value than direct feedback from your customers and the incremental nature of Agile is optimized to receive and respond to customer feedback.

In your Sprint Retrospectives, the team should consider what is impacting outcomes which might include prioritization of user stories, complexity, competence of your team, changes in scope, accumulated Technical Debt, defect rate, insufficient test automation, poor tooling. Etc. You should consider measuring (1) technical debt items on backlog; (2) rework percentage; (3) the rate at which defects are found and fixed; (4) the rate at which scope is added; and (5) user story complexity. These metrics should be actively discussed and managed by the team to improve its performance.

Ultimately, the Product Owner is accountable to stakeholders for the release of value, ROI, and the rate at which business value is delivered. This is where management and other scaling mechanisms can help in personnel evaluations and to put in place the right mechanisms for individuals and teams to learn, grow, and succeed.