Story Points and Sprint Duration

There are a lot of schools of thought on story points. In my opinion, the conversation about "measuring complexity" is unhelpful. I feel it should be a team decision, but if using story points, I would vote that they should be an estimate of relative amount of work for the team to complete the task. I feel most teams are better at estimating relative size than relative complexity, as identified complexity is often mitigated by extra refinement.

 

However, I see a lot more benefit in liberating teams from just looking at a number of story points to be completed within a sprint. For instance, a team may eventually realise that items above a certain number of points are less likely to be completed, and may look at ways to break them down in to smaller items.

One possible future step may be to abandon story points altogether, and for a team to estimate "yes" or "no" to whether an item can be completed within a certain timeframe (e.g. 3 days)

Once teams apply consistent rules for breaking down items to a smaller size, throughput (total number of items done in a sprint) becomes a very powerful alternative to velocity (total number of points).

I am new to agile and confused how would the scrum team pick a number of user stories from the product backlog that fit in the sprint duration while user stories are measured in Story Points

During Sprint Planning, the team should look at the forecast of work in aggregate and decide whether or not it seems achievable in the timebox. The corresponding number of story points can be used as a baseline for future velocity estimation and improved through experience. However it is always important to look at a forecast in the round, and the achievability of the Sprint Goal, rather than to become story point accountants.

Agile -> preaches 'Relative Estimation' rather than 'Precise Estimation'. Following are the factors involved:-

1. Large scope of work can never be precisely estimated. There is no point in doing this. When we take a scope of work / requirement to estimate; and its large; its impossible to estimate the effort and scope involved exactly to do the work. Because the uncertainities are too many; and as we start the work; unanticipated impacted work crop up.

2. Break down into smaller portions: To bring down uncertainity - the work needs to broken down into small portions; that can be estimated reasonable.

3. Team View: The time required for a work to be done depends on the complexity of work also the skillset of the person involved. What one can do in an hour; another can do in half hour. Hence the estimation needs to be done collectively by the Team thats doing the work

4. Story Points: Now coming to Story Point:- Team thats working together for a long time need to have an impression on the smallest scope of work that can be done in a standard time - say an hour or a day. This piece is given 1 Story Point. Relative to that all the other pieces of work are determined -> twice bigger ; thrice bigger and so on

5. Team Velocity:- Now that the team works on standard timeboxes; the amount of work in terms of story points can be predicted. This becomes their velocity; and the team picks work based on their velocity. WIth time as they gain knowledge and skills; the velocity keeps improving

Hi Basem, 

Above Anupama, Ian and Simon described you the answer for your question.

I just want to add that if story points are not convenient for your team I guess it will be more effective to change metric. For example, you may choose ideal days/hours. About 1,5 years ago our Scrum team used this metric and in general, it was ok. 

Thank you all for your replies that add to my knowledge and clarify a lot of things about estimation in agile.

The main point that I was asking for is that, as I know till now, user story size measured in story points doesn't correspond proportionally to the duration required to implement it. So, measuring team velocity in story point doesn't make sense. Also, any forecast (burn-up/burn-down charts) based on story points may lead to false indications since a big size user story may take time less than a smaller one and vice versa.