With the development team of 10 members. Project should be completed in 2 sprints. If the team plan to change the story points, does velocity of the team change? If so which type of velocity changes?
velocity of the team– priyankaApr 29, 2019 at 16:16
What do you mean by 'type of velocity'? To my knowledge, there's only one type. Story points/sprint.– SarovApr 29, 2019 at 16:17
SO here I meant, Planning velocity, initial velocity, avg velocity, ideal velocity.– priyankaApr 29, 2019 at 16:21
Where are you getting those from?– SarovApr 29, 2019 at 16:27
An "Average" of Zero or One Measurements is Called a "Guess"
Two Sprints is not enough time to norm a team's velocity, especially if it's a new team or a new project. On a fixed-length project like this, velocity is unlikely to be anything other than a guess, and will therefore have extremely limited value.
Don't Misuse Velocity
There is also no such thing as "ideal velocity," and some of your other terms are likewise suspect. Velocity is a trailing metric based on a stable estimation-of-effort technique, generally calculated as a statistical mean or statistical range. It is most explicitly not a measure of productivity, or a predictive metric of value. At best, it provides a rough baseline to estimate team capacity, and a sanity check to ensure the team doesn't over-commit when selecting work related to the Sprint Goal.
If you're using velocity to plan your Sprints. or to select work by volume rather than in relation to the Sprint Goal, then you're using the metric incorrectly. Don't do that.
Actual velocity does not change based on story points or planning or looming deadlines or any other surrounding factors. Actual velocity merely refers to "how much work does the team get done", which is independent of planning, estimates, etc. It depends entirely on scope and time spent.
The team wanting to change the numbers attached to a piece of work thus have no impact on the chances of them being able to complete the story. The number attached to a piece of work has no true relation to the size of the piece of work. This is why trying to talk a team into a lower estimate is a waste of time, and why placing more items in a sprint than velocity suggests can be done isn't going to help you finish sooner, it'll just make you fail the sprint.
Unless you're changing what needs to be done or what time is available to do it in, nothing tangible is changing when people modify story points, or update the planning, or move the velocity. All of these things are reporting information that you can use to adjust real parameters, which are essentially just "scope" and "time available".
The numbers that the velocity generate are likely to change based on changes to story point estimations. Velocity fluctuates over time regardless. You'll see how velocity changes as you recalculate it after each sprint. But it's generally a bad idea to attach meaning to the velocity-numbers; they're a forecasting tool, not a goal.