Brand-new Agile / Scrum teams (or teams with recent turnover) can’t say predictably what their velocity is. I see teams struggle with this a lot, and they struggle because there isn’t a clear answer. Formally, a team’s velocity for a sprint (or iteration) is the sum of the points for all completed user stories that have met the team’s Definition of Done. A team needs several sprints of working as a unit to produce enough data for a predictable, reliable velocity. Understandably, teams that haven’t finished a sprint together yet don’t have this data. Teams need at least three sprints to get an average at all, and that average is rarely steady until 5-10 complete sprints.
So what’s the best way to get through that early phase?
The short answer: make an educated guess.
Remember that velocity only serves two purposes:
Help the team know when they have selected enough work during sprint planning.
Help the Product Owner know approximately how many sprints it will take for the team to finish implementing the groomed backlog items (which, if applicable, helps the Product Owner with PI Planning).
For the first couple of sprints, have the team plan until they feel like they have a workload that they’re comfortable with and confident that they can finish by the end of the sprint. It’s wisest to work on the top-priority items first in case they overestimate (to satisfy the product owner) and have one or two stories in reserve to pull into the sprint in case they underestimate and finish early.
An alternate suggestion (using SAFe*), which assumes the team must synchronize tightly with a larger organization, is to simply allocate “8 points per team member for a 2-week sprint.” Using a standard 8 is a good default, since it normalizes story point sizes for Agile teams working together at scale. There are some downsides to applying this method. Specific teams can’t know what 8 points of work looks like for them until they have finished several stories of different sizes. On that first day, a new college grad’s “8 points” probably doesn’t match a seasoned developer’s. And even experienced developers who’ve worked on different teams will have different senses of size. And on top of that, the new team will have new synergies and gaps between members that didn’t apply to former teams, further throwing off the numbers.
Having used multiple definitions for points in the past (I worked with one team of 4 with a velocity of 130 and another team of 7 with a velocity of 13), I now prefer starting with that 8 points per person standard. But I also keep the downsides in mind, as that does not mean that every team of 7 engineers will have a velocity of 56, or even that they will produce the same amount of work. Again, it’s just a starting point.
If you are going to apply a standard 8 points per person method, plan the story point backlog for your first sprint not in terms of hours or days, but in terms of a range. Any story that’s going to take most or all the sprint should be 8 points (or 13 if two or more team members will work only on that story for the whole sprint). Eventually you want all your stories to be small: 5 points or less if possible (i.e. half of a two-week sprint or less to implement), but it’s difficult for new teams to break down every big story.
Stories that you think will only take a day or two to finish should be 1 or 2 points. It’s okay if you’re wrong and they take more time, or less. Story points are only an estimate. Don’t spend excessive time debating whether a story is 2 or 3 points – if there’s doubt, choose the larger size. But do have the discussion: this builds a shared understanding of all the work required to fully implement the story, which is how your team develops a reliable velocity.
If, after a few sprints, you still have a lot of outliers that heavily affect your average (“These 5s all took most of a sprint!” “This 2 and this 5 took about the same amount of time.”), it may be worth either
a) re-estimate your previous story sizes and recalculate your team’s velocity or
b) go back to the SAFe baseline (8 points per team member over two weeks) until
things stabilize
Unless your completed story points are excessively inconsistent sprint to sprint though, it's not usually worth the disruption and time spent to go back over your old story sizes.
That’s it. Scary as it is, take a reasonable guess and start your work from there. In later sprints you should have the data you need to properly use relative sizing techniques.
*The full description of how SAFe establishes velocity is:
For every full-time developer and tester on the team, give the team 8 points (adjust for part-timers)
Subtract one point for every team member vacation day and holiday in the iteration
More details on SAFe’s iteration (a.k.a. sprint) planning can be found at https://www.scaledagileframework.com/iteration-planning/.