Torak has a new web site at www.torak.com.
Please update your bookmarks.
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 scale like 0, 1, 2, 3, 5, 8, 13, 20, … Even though the scale is rough, if the team is 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. We recommend setting a maximum of 3 rounds facilitated by the Scrum Master to reach consensus. If we can't point a story then the story must be presented at a later time with the necessary adjustments that may include rewording the story, updating the acceptance criteria or breaking up the story.
It is quite common for questions to come up about the intent of a story or implementation constraints, dependencies and assumptions. It is recommended that the product owner and lead architect attend the pointing session in order to address these questions. These questions often lead to discussions that resemble a product design sessions. 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 introduce story pointing is to pick a moderate sized story among the first several stories and assign it 5 or 8 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. We recommend setting a maximum of 3 rounds facilitated by the Scrum Master to reach consensus. If we can't point a story then the story must be presented at a later time with the necessary adjustments that may include rewording the story, updating the acceptance criteria or breaking up the story.
It is quite common for questions to come up about the intent of a story or implementation constraints, dependencies and assumptions. It is recommended that the product owner and lead architect attend the pointing session in order to address these questions. These questions often lead to discussions that resemble a product design sessions. 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 introduce story pointing is to pick a moderate sized story among the first several stories and assign it 5 or 8 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.
