How to decide how many story points to take up in the first sprint

Vishal,

This is a common experience with those starting out in Scrum, so take a breath.

I can tell you from my experience and understanding how I managed this with new teams:

1) Firstly, there isn't such a thing as a correct story point. It is whatever the team wants it to be. That probably is even more confusing, so let me explain a little.

The story points simply represent categories of effort. An “8” story is larger than a “5” story, but is smaller than a “13” story. One approach is to have the team start out with a medium-sized story, and agree on what value that represents. They can then begin working to estimate stories in “relation” to the first story.

Another approach is to have the team group all of the available stories in categories of similar size. There are plenty of examples available on the internet to guide you through this exercise. Almost always, the team will come up with no more than 5 categories of effort (usually 4-5). Then just ask the team how they want to apply the Fibonacci scale to them (1-2-3-5-8, 3-5-8-13-21, etc).

It is critical after a few sprints to have the team briefly revisit their past estimates to reinforce the team’s understanding of what an “8” is, or a “3” is, for example.


2) For the first sprint, have the team estimate in story points, but don’t use them to determine how much work to accept. Simply work with the team to have them collectively judge how many stories they feel they can finish in the first sprint.

The story points will not become valuable until the team executes a few sprints anyway, and a velocity metric can be identified. Then the team can look at their velocity as a guide for how much work they can comfortably accept each sprint, and the PO can look at the velocity metric to estimate how much of the product backlog can get done by certain dates.

Important! Estimates are just that, estimates. They are the best guess based on the information currently on hand. They are a forecast, not set in stone in any way.


3) The story points are only to capture the size of the effort needed during the sprint (development, testing, perhaps additional analysis) to complete the story according to the team's Definition of Done. Pre-sprint grooming for current sprint stories, and grooming for future stories, are certainly activities that need to take place, but they are not captured in the story point estimation. You can definitely come up with other means to quantify and report on those efforts if needed.

The first Sprint is a Learning Sprint. Whatever number of points the Dev Team will forecast, there is little chance that the mesured Velocity at the end of the Sprint will match this forecast.

Just guess quickly, don't waste too much time looking for a cristal ball, and move forward.
At the end of your first Sprint, you will have a mesured Velocity wich will really help the Dev Team to have a much better forecast for the second Sprint.

I say, Just go with your guts.

There is a high chance you will be wrong, even after a few sprints down the road. But as the team matures, you will eventually make it almost right most of the time.

Use this opportunity to set the right course and the right expectations. Development Team members are not meant to be story point accountants. As far as estimation is concerned, they need to forecast an increment for delivery which ought to be of value to the Product Owner. The purpose of estimation is to help a team get its arms around how much work it can do in a Sprint.

The best thing to do is to look at the totality of the proposed work and decide, as a team, if it is realistically achievable to deliver a corresponding increment, to the satisfaction of the Definition of Done, in the time-box proposed.

Estimates for individual items can be relatively sized on that basis. T-shirt sizing can work as it is qualitative, and keeps teams out of the weeds about what the numbers are. Sizes can be mapped to a schedule of points afterwards.

Posted By Olivier Ledru on 26 Mar 2016 09:31 AM
At the end of your first Sprint, you will have a mesured Velocity.

A common approach for calculating velocity is to average at least three sprints. After the completion of a team's initial sprint, you would only have the number of story points they completed, in my opinion. That is not representative yet of how much work the team can complete each sprint, especially with the number of issues and hurdles a team experiences during their first sprint.

I would not refer to the results of a single sprint as representative of a team's "velocity", used both as a team guide for understanding their throughput each sprint, and as a metric for Release Planning.

You cannot calculate velocity because velocity is a mesure.
You can estimate the capacity of the Dev Team for the Sprint, and after the Sprint, you can see if the estimated capacity matched the actual velocity.
And yes, for that estimate, an average of the N last sprint is probably more accurate that only the last sprint.
Around me, some team calculate an average of the 5 or 8 last sprints, without the best sprint and the worst sprint.

Olivier, unsure about your statement that you cannot calculate velocity. How else can you derive it?

Velocity is a reflective metric calculated by averaging the total amount of story points completed over the number of sprints completed.

If a team has three completed sprints of 65, 75, and 100 story points, then their velocity at that point is established at 80 story points (65+75+100 / 3). Isn't that a calculation?

That "metric" of 80 can be used not only as a guide for the team in determining how much work can be comfortably accepted in the next sprint, but also as a forward-thinking metric for the business in estimating how much work a team may complete by a given date in the future.

By definition, to "measure" something requires comparison to an established standard (i.e. - dimensions (ex: meters), units (ex: liters), other people, etc.). There is no set "standard" regarding velocity.

You can measure a team's completed story points against their known velocity, for comparison purposes, but the velocity value must be calculated first.

How is technological complexity considered in deriving story points?

Story points are biased more on efforts/duration, but what are the measures available to indicate technological complexity of a story?

Thank you.

Story points are biased more on efforts/duration, but what are the measures available to indicate technological complexity of a story?

I don't think there are specific ways to highlight only technological complexity. The story point is for a particular story is achieved after considering all the facts - the technological complexity, the effort, the uncertainties (if any) etc. and is a measure of how much effort is needed to complete the particular story when compared with other stories in the backlog.

--Anoop

The purpose of estimation is to help a team figure out how much work it can take on. If the complexity of an item is likely to affect this significantly, then complexity should be taken into account.

Teams might see complexity as being important when determining effort, and hence consider it implicitly.