TL; DR
Basically, your entire set of planning assumptions is non-agile. You need to revisit how you're planning your iterations, and how your team plans to estimate the work it thinks can be completed for the current iteration. A more detailed analysis follows.
Detailed Analysis
We know that long term planning(Release planning) should be in story points. [sic]
No. Agile release planning is done in iterations. Therefore, a Scrum project plan will estimate an approximate range of iterations needed to reach the minimum viable product or complete the initial Product Backlog. This is only an estimate, as the backlog contents will change over time, and length and accuracy of estimates will also change along with the Cone of Uncertainty.
But for sprint planning, it should be commitment based.
Again, no. Sprint Planning is capacity-based. The only point of tracking (or creating an initial guesstimate of) the team's average velocity is to find the team's sustainable capacity for work over time. While the team must be sure never to over-commit to work in a Sprint just because the velocity range or average says that there should be available capacity, it is the team's responsibility to plan for the current iteration by taking team composition, availability, and other factors that affect the present Sprint into consideration.
Saying that Sprints are "commitment-based" is likely to be used as an emotional bludgeon to get teams to commit to more work than they should, because of course team members should be "committed." However, that's a misuse; in the real world, team capacity should generally be reduced but rarely inflated during planning. If the team has under-committed, then additional work can be peeled off the Product Backlog as needed, but trimming scope is almost always politically fraught and often puts the Sprint Goal at risk. So, don't do that.
Capacity can be a relatively-objective metric. On the other hand, commitment (much like patriotism) can't be measured unless you're asking people to "make the ultimate sacrifice," which is sort of antithetical to the entire premise of agile sustainability. Never commit to a death-march.
For a three week sprint, how big should be each story for a person?
This deserves a whole book filled with "no." Stories are never sized for, or accepted by, an individual. All stories are estimated based on the full, coordinated resources of a cross-functional team working together to complete each story. The stories are accepted or rejected based on whether:
- They are essential to the current Sprint Goal.
- They will fit within the estimated capacity available for the current Sprint.
A single Product Backlog Item can be anywhere from 0 story points up to the maximum available for the entire Sprint. However, a good story that meets the INVEST criteria is generally composed of Sprint Backlog tasks of around 0.5 days to 2.0 days in length. Remember that the smaller the task or story, the more accurate the estimate usually is, so a dozen 5-point stories (when accurately estimated) are generally more reliable than a single 60-point story. However, your team maturity and estimation accuracy may certainly vary.
