Story Pointing
in
The purpose of story points is to give stories a rough size estimate. Story points are not supposed to be precise, so it’s recommended to use a rough scale like 1, 2, 3, 5, 8, 13, 20, … Even though the scale is rough, if the team is fairly consistent in assigning the same number of points to stories of similar size, their velocity (number of points completed per sprint) will tend to stabilize over time.
The development team is responsible for assigning story points. The recommended method is for each team member to select their estimate independently. After the high and low estimates (and anybody else) explain their reasoning and a short discussion, each team member again selects an independent estimate. This process continues until consensus.
It is quite common for questions to come up about the intent of a story or implementation constraints/dependencies/assumptions. It is recommended that the product owner and architect attend the planning meeting in order to address these questions. These questions often lead to discussions that resemble a product design meeting. If kept at a high enough level, such discussions can be very productive in helping understand what a story really entails. However, these discussions should never be allowed to get more detailed than absolutely necessary to estimate the size of the given story.
Given that story points have no unit of measure, it is hard to get started for the first time. A good way to story pointing for the very first time is to pick a moderate sized story among the first several stories and assign it 5 or 8 story points, and then point the next story in relation to that story. Once more than just a few stories have been story pointed, it's recommended to use triangulation to estimate story points - questions should be asked like “Is this story more like story A or story B?” After having already pointed stories in the past, it is best to triangulate with respect to past stories in order to keep the team’s velocity calibrated to the same relative story point values.
The development team is responsible for assigning story points. The recommended method is for each team member to select their estimate independently. After the high and low estimates (and anybody else) explain their reasoning and a short discussion, each team member again selects an independent estimate. This process continues until consensus.
It is quite common for questions to come up about the intent of a story or implementation constraints/dependencies/assumptions. It is recommended that the product owner and architect attend the planning meeting in order to address these questions. These questions often lead to discussions that resemble a product design meeting. If kept at a high enough level, such discussions can be very productive in helping understand what a story really entails. However, these discussions should never be allowed to get more detailed than absolutely necessary to estimate the size of the given story.
Given that story points have no unit of measure, it is hard to get started for the first time. A good way to story pointing for the very first time is to pick a moderate sized story among the first several stories and assign it 5 or 8 story points, and then point the next story in relation to that story. Once more than just a few stories have been story pointed, it's recommended to use triangulation to estimate story points - questions should be asked like “Is this story more like story A or story B?” After having already pointed stories in the past, it is best to triangulate with respect to past stories in order to keep the team’s velocity calibrated to the same relative story point values.
