Initial sprint velocity problem
When starting a new project potentially with a new team or new technology using Scrum, the often asked question is: “How to determine the number of story points or velocity for the first sprint?” (more about it on StackExchange and Quora) The reason for this question comes from management pressure to have estimation upfront (so they can determine the expenses). Scrum proposes the use of story points to measure team efficiency. Velocity is the mean value of story points that team can accomplish per sprint, and it represents a relative measure. By using past velocities, teams can predict their future velocities. But, new teams don’t have the record of past velocities.
If team is well established, but working on a new project, using its past velocities to predict future ones is a usual way to go. If they need to use a new technology, past velocities have to be adjusted by taking into consideration the learning curve. The hardest case is a new team, working on a new project which is possibly more complex, with members that don’t know each other. Past data is not available and using data from other teams doesn’t make sense. Situation is more complicated if whole company is new to Scrum. There are 2 alternative solutions: Convince management to wait or give them an arbitrary number (guesstimate). Convincing management or negotiating an open position is sometimes difficult. That means they are going to have the number they want after a few sprints (possibly months). Initial sprints are there for calibration after all, but managers ought to know estimate KPIs ASAP.
Alternative is to give management a guessed number or false reference. It is expected that team would commit to that number. Ability to plan is the crucial thing given to the team and they are responsible for execution of planned activities. But preliminary estimates usually do not give results. Giving too high number would cause a burn out. On the other hand, management wouldn’t be satisfied with lower number. One of their responses could be to add more people so velocity can go up (which isn’t in collision with Brook’s Law since it’s not the end of the project). From psychological standpoint, giving lower estimate causes team to meet the DOD and to have sense of accomplishment (which is better in the long run).
There is a way that can make a guesstimate more confidential, and it requires several steps. First of all, the team have to estimate product backlog (using story points). Estimation techniques are usually time based, not work effort based. Most popular ones are: Similarity, reference class forecasting or using past data, expert advice, 3 point technique, Delphi technique and variations etc. Planning poker proposed by James Grenning is the most widely used technique in Scrum. It is a variation of Wideband Delphi technique proposed by Barry Boehm (who also proposed a spiral model). T-Shirt sizes are additional option, apart from Fibonacci scale which is used in most cases.
After estimating backlog, story that is estimated with 2 story points is taken as a reference story. That story is broken down into tasks by the team. Resulting tasks are time estimated using Planning poker (instead of story points, values on cards represent hours). After that all values for tasks are added together. Resulting sum represents approximate number of hours needed for reference story. By using the amount of hours for reference story, amount of hours per point can be calculated. Because reference story has 2 story points, hours per point is calculated by dividing the number of hours for reference story by 2. More reliable hours per point approximation can be achieved by taking mean value of time estimations of multiple reference stories.
The next step is to calculate team capacity, or the amount of hours team would work on a project per sprint. From cumulative team hours, velocity can be calculated by dividing it with hours per point approximation. For example, if team can work 120 hours, and hours per point is 5, than velocity approximation is 24. When expressing this number, a good option is to express it as a range (by taking into consideration the availability of team members).
Described steps lead to a number which isn’t based on real data. This concept should be used when management is determined about getting a number. After all, team delivers stories, not points. In this article is suggested to use common sense and, after described steps, go through stories with asking a question: “Are we confident we’ll be able to complete this story as well?”
Whole another problem is the aim to deliver a Potentially Shippable Product or Minimum Viable Product (difference here) at the end of the sprint. By prioritizing backlog, Product Owner influences team effectiveness. Initial sprint should deliver stories that have the biggest value for the customer (or the highest priority in backlog). On the other hand, that can influence team’s technical or architectural decisions, which can have wider repercussions on future sprints. In that case, Product Owner should consult the team before making such decisions.
There are different alternatives for solving the initial sprint velocity problem. Environment and managerial strategy are playing the biggest role in deciding between alternatives. When management is categorical, proposed steps can give wanted result. Though that result is not based on realistic background.
