In Agile Software Development, often we come across practical situation when we have to carry-out high-level planning or initial release planning prior to starting a new product’s development. Project team’s Velocity being the important component for this planning exercise, the concern looks valid to a large extent, if it’s not known. Velocity is required to determine the number of iterations (sprints) and high level timeline along with number of features that can be delivered. This condition gets aggravated to plan for initial few iterations, when the project is starting with entirely new team getting transitioned to Agile methodology.
There are couple of ways to predict the raw velocity to do the initial high-level or release planning and fine-tune that as team completes couple of iterations, and get more maturity and confidence on their velocity. For the sake of initial high-level release planning following are the possible options that can be used to determine team’s initial velocity –
1. Use Organization’s Historical Data
You can use available historical data from organization experience to perform initial high-level planning, provided the project is more or less on similar technology stack, business domain and to be executed by almost similar multi-functional team. This velocity should be normalized considering factors like project complexity, team experience and skills, expected level of customer involvement, requirement evolution, technical/environmental factors and risks/contingencies foreseen etc.
2. Leverage Experience & Expert Judgement
If organization data is not available than you can use your experience and expert judgement. However, in this case you can calculate velocity by using your Project Size (in StoryPoints), Productivity or Efforts (in Person Days) considered to complete one Story Points and Average Team Capacity per Iteration. Possible formula could be Raw Velocity = (Project Size * Effort per Unit StoryPoint) / Avg. Team Capacity. Please note that you should rationalize the Productivity i.e. Efforts per StoryPoint with actual productive hours only which can be obtained by reducing non-productive hours (like meetings and sprint ceremonies etc.) from the available hours. Also do consider above mentioned influencing factors while release planning.
3. Involve team to obtain Velocity
If you have available project team than it make sense to engage them to decide on the initial raw velocity. They should jointly decide to pick up user-stories that they think would be able to complete in the first iteration. Likewise, they should pick up three to four sets of different user stories that can be completed in one iteration and then average out the StoryPoints of all selected sets. This average StoryPoints would be considered as Initial raw velocity, which can be used to plan the releases.
Pitfalls to Avoid
The above options to get raw velocity for initial level of planning comes with tradeoffs. Hence as the project progresses, subsequently, team should use the actual velocity observed from previous completed iterations to plan for future iterations and releases. The process of planning should be continuous and evolving as the project progress and team know their efficiency.
As far as possible, engage team to do sizing and planning exercise. Agile practice suggest to let the project team do their planning work so the release and delivery commitment becomes the whole team’s responsibility and not just the Scrum Master or Product Owner.
Where the third option is applicable only when you have the project team in place. But if the project team is unavailable especially during product envisioning, pre-sales / proposals stage and high-level plan need to be done in order to determine the tentative cost and time; first two options can be used with caution. Agile suggest no two team’s velocity should be compared and hence past performance of different team are indicative of future performance of another team.
Conclusion: Initial release planning or high-level planning done with raw velocity data are assumed to be rough and gives project team a direction and short-term goal to start. Plan need to continuously evolve based on course correction with team experience, architectural excellence, requirement evolution, customer participation and feedbacks.