When first implementing Scrum within a team, how should you go about determining the amount of story points that are in an initial sprint when you have no idea of the team's velocity?

Should you base this on an estimate of hours and only use the points at a later stage?

  • 2
    How long will be the Sprint? – Gopi Mar 18 '11 at 9:02
  • Well thats naturally a consideration - in my case its 1 week for a team of 3 - but even on larger teams, how do you initially set the work for the duration of the sprint before you know the team's velocity.. – Mysterion Mar 18 '11 at 9:13
  • @Sri Kumar: How does it matter? – azheglov Jul 5 '11 at 12:46

You have no historical facts to draw upon, so I suggest that you don't bother with any guesses at all. Trying to calculate velocity based solely on some formula is just a waste of time.

Simply estimate enough stories and let the team work on them during the first sprint. They'll finish what they finish anyway. After this initial sprint, you'll have your actual velocity. Since you sprints are (excellent!) 1 weeks, you'll get the real velocity very early on.

| improve this answer | |
  • "estimate enough stories"? – Armand Jul 6 '11 at 13:45
  • 1
    More than they can reasonably finish in the first iteration. – Martin Wickman Jul 6 '11 at 14:10
  • 4
    there's an implicit estimation of velocity required to do that ;) – Armand Jul 7 '11 at 11:56

Nobody can say you how many story points can you take for your first sprint. First of all story point is unitless value. You should not make initial decisions like 1 story point = 6 hours because in many cases it will run against you later on. Also each project can have different "size" of story points.

Commitment should be done based on Planning meeting with product owner. You will go through user stories and PO will explain some details about them. He will also provide some acceptance criteria (definition of done). Planning meeting is time bounded (based on sprint length and size of the team) so the first observation is how many user stories you were able to discuss. Based on the information received from the PO the team should be able to make professional judgement of how many of discussed user stories can be done in the sprint. Because the team knows that it is initial sprint and nothing is done yet, the team will probably commit only to a small amount of work but this will increase in future sprints.

Pure story points value should not be used for planning and time estimating. It should be used to describe relative complexity but still 8 story-points can mean something between 6-12 (Fibonacci) story points in reality so saying that 8 story-points equals to 4 days is really dangerous because it can be also 3 or 6 + "waste" (overhead) in initial sprint.

One of the main agile tenets is 'Empower People'. Planning and commitment is exactly that empowerment you give to the team. Team is responsible for delivering commuted user stories but of course they can fail and they mustn't be blamed for commitment failure in initial sprints. Initial sprints are for calibration.

| improve this answer | |

One technique is to select a few middle sized user stories, give them an arbitrary size in points and have them broken down in tasks by the team. Then the team estimates each task in hours, which once summed up gives you a rough estimate of work hours per story point. Knowing the total work capacity for the sprint, you can extrapolate to get a number of story points you could theoretically complete in the sprint.

This shouldn't be interpreted as an exact goal to reach though, and should be forgotten as soon as the first real velocity of the team appears, when first sprint is over.

| improve this answer | |

You have to guess, as you have no information to go on yet. However, if you've already done work outside Scrum but with the same team, you might be able to use your previous estimation experience to guide your guesswork. Or you could just take additional stories until you run out of time.

| improve this answer | |

You don't rely exclusively on point estimates for sprint planning anyway. During planning, your velocity can help you to quickly "propose" a sprint plan and/or assist with your sanity check before making the final commitment; but, no matter how much velocity data you have, the team ultimately needs to commit to stories, not points.

Bear in mind, 5 x 1-point stories do not equal 1 x 5-point story for exceptionally small values of 1. They are only roughly equivalent for the purpose of long-term planning.

And that's where the primary value of the points comes into play: when you need to guesstimate when an epic or release can be completed, or whether you have too much on your plate for a scheduled release-date.

That said, a successful team will eventually find itself planning about the same number of points each sprint. But, there will be variances based on the particular stories in that sprint. A successful team can articulate during planning why some 5-point stories don't actually offset all 5 of the initially proposed 1-point stories ...

| improve this answer | |

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.