How to increase capacity of the team member by one point?
I have a specific scenario where a team member asks me to increase his capacity by one point by September. He accomplished 14, 13, and 27 user points over 14 working days, and in one of the sprint he completed 3 points over 4 working days( that was vacation, sick leave, and holidays) . How can I guide him and ensure he can increase his capacity by 1 point by September?
Why are you measuring capacity of an individual? Capacity is typically measured at the team's level and represents how much work the team can do in a given time, such as during a Sprint. You often don't want to measure individuals.
Since capacity is how much work can be done in some unit of time, there are only a few ways to increase capacity. You can find and eliminate waste from the process and stop doing things that aren't useful or valuable. You can find ways to automate repetitive tasks or otherwise reducing manual efforts. However, there are maximum limits to capacity.
He accomplished 14, 13, and 27 user points over 14 working days
Points are not accomplished, Sprint Goals are, and the Developers are jointly accountable for meeting them. The only purpose of "points", if they are used at all, is to help the Developers get their arms around how much work they can collectively take on in a Sprint so a meaningful Sprint Goal can be satisfied. Everything else reduces to value delivery and empirical process control.
What is expected to change to the individual or to the team by increasing 1 point ?. Is there performance target for that person or its team velocity target ?. Counting story/user points may not help to achieve the intended outcome. There are many non-quantitative indicators that you can use to improve individual or teams effectiveness.
Do it like everyone else does. Add 1 story point to a particular story that the developer decides to take on. I'm not saying this is a good thing but it is how this type of issue is done.
As everyone above has stated, there is no use in doing this. It puts the wrong focus on work being executed. Story points are an guess (i.e. estimate) that the Developers make on how much relative work is needed to satisfy a story. They are made with partial information. No one can tell you how much work something will need until they start doing it. As the work progresses, new information is gained and work is done to accommodate. This article from Ron Jeffries is good for explaining the origin of, use of, and fallacies of Story Points.
The request from the Developer leads me to believe that they are being judged on how many "points they do". Really bad idea because that often leads to Developers inflating their estimates in order to get better ratings.
I agree: I would not use points as a measure for indivuduals, only on team level (and I don't recommend communicating velocity with stakholders or management).
It would appear however that the employee has an underlying question about his productivity. That can be personal in nature, but it could also be a sentiment about his 'worth' as compared to other team members. A personal coaching session with this employee sounds more fitting to me, to find out what is really the issue here.
team member asks me to increase his capacity by one point
It is worth mentioning that 'Capacity' is usually understood as the time available to the team during the Sprint. Contrary to 'Velocity' which shows how much of the Product Backlog the team can turn into Done in a single Sprint. So, the teams usually use time units for Capacity vs story points for the velocity.
I like the comparison to the car engine. Let's say the capacity is 1 liter. In the 70's such an engine could generate like 40KM of power (velocity). Thanks to continuous improvement over the years modern engines can generate 150KM.
Your Scrum Team can also improve over time. But it is not only about the individuals but the whole team improving their working methods.
As in the car engine, it is not about one part of it but the entire engine improvement to generate more power.
However, the Velocity alone is not enough. The team needs to have the right goal and generate Value on each Sprint. Measuring the Value of the Sprint outcome is more important.
Like with the car, you can use its power and drive around without the purpose and get lost. Or you can drive in the right direction and achieve the goal. Often a less powerful car with a better driver can drive you further.
Increasing a single person's story point count by 1 is not a concept in Scrum or Agile. The above posts describes well that story points estimation is only an estimate for the whole team.
Not to be rude, but it seems Scrum is only done in name, and the underlying principles are not implemented. The team should be allowed to self-manage and the team decide how many items to pull in during planning. Story points are only an estimate to help the team during planning to determine which items to pull in. Measuring story points to "drive" the team or individuals is not the Scum idea. Scum and Agile use self-managing or empowered teams along side a sprint goal, to increase motivation.
There is another problem here. The whole team work on a backlog item. To "assign" the story points to one person imply that the team members work in isolation from one another.