Agile teams separate estimates of size from estimates of duration. There are two measures of size:

1. Story points

2. Ideal time

##

- Story points are a relative measure of the size of a user story.

- A point value is assigned to each item when we estimate story points.

- Relative values are more important than raw values.

- A user story estimated as ten story points is twice as big, complex, or risky as a story estimated as five story points.

- A ten-point story is similarly half as big, complex or risky as a twenty-point story.

- The most important thing that matters are the relative values assigned to different stories.

- Velocity is a measure of a team's rate of progress per iteration.

- At the end of each iteration, a team can look at the stories they have completed and calculate their velocity by summing the story point estimates for each completed story.

- Story points are purely an estimate of the size of the work to be performed.

- The duration of a project is not estimated as much as it is derived by taking the total number of story points and dividing it by the velocity of the team.

##

Ideal time and elapsed time are different. The reason for the difference, of course, is all the interruptions that may occur during any project.

- The amount of time a user story will take to develop can be more easily estimated in ideal days than in elapsed days.

- Estimating in elapsed days require us to consider all the interruptions that might occur while working on the story.

- If we instead estimate in ideal days, we consider only the amount of time the story will take.

- In this way, ideal days are an estimate of size, although less strictly so than story points.

- When estimating in ideal days, it is best to associate a single estimate with each user story.

- Rather than estimating that a user story will take 4 programmer days, 2 tester days, and 3 product owner days, it is better to sum those and say the story as a whole will take nine ideal days.

1. Story points

2. Ideal time

##
*Estimating Size with Story Points*

- Story points are a relative measure of the size of a user story.

- A point value is assigned to each item when we estimate story points.

- Relative values are more important than raw values.

- A user story estimated as ten story points is twice as big, complex, or risky as a story estimated as five story points.

- A ten-point story is similarly half as big, complex or risky as a twenty-point story.

- The most important thing that matters are the relative values assigned to different stories.

- Velocity is a measure of a team's rate of progress per iteration.

- At the end of each iteration, a team can look at the stories they have completed and calculate their velocity by summing the story point estimates for each completed story.

- Story points are purely an estimate of the size of the work to be performed.

- The duration of a project is not estimated as much as it is derived by taking the total number of story points and dividing it by the velocity of the team.

__There are two approaches to start with:__**Select a story that you think is one of the smallest story and say that story is estimated at one story point.**__1. First Approach:__**2. Second Approach:**Select a story that seems somewhat medium and give it a number somewhere in the middle of the range you expect to use.##
*Estimating Size in Ideal Time*

Ideal time and elapsed time are different. The reason for the difference, of course, is all the interruptions that may occur during any project.

- The amount of time a user story will take to develop can be more easily estimated in ideal days than in elapsed days.

- Estimating in elapsed days require us to consider all the interruptions that might occur while working on the story.

- If we instead estimate in ideal days, we consider only the amount of time the story will take.

- In this way, ideal days are an estimate of size, although less strictly so than story points.

- When estimating in ideal days, it is best to associate a single estimate with each user story.

- Rather than estimating that a user story will take 4 programmer days, 2 tester days, and 3 product owner days, it is better to sum those and say the story as a whole will take nine ideal days.

## No comments:

Post a Comment