Planning 2 - Estimation Mechanics
Email this Mix
Slide 1 - Planning 2:Estimation Mechanics
- Emerson Murphy-Hill
- Creative Commons Attribution 4.0 License.
- Material Produced by NCSU Software Engineering Faculty.
Slide 2 - Deriving an estimate for a user story
- Relative to (several) other user stories
- Triangulation: little bigger than that “3” and a little smaller than that “8”
- Expert opinion
- Rely on gut feel based on (extensive) experience
- Disadvantage for agile: need to consider all aspects of developing the user story, so one expert will likely not be enough
- Break up into smaller, easier-to-estimate pieces/tasks.
- Need to make sure you don’t miss any tasks.
- Sanity check: does the sum of all the parts make sense?
- Planning poker
- Combines expert opinion, analogy, disaggregation
Slide 3 - Planning Poker(http://planningpoker.com)
Slide 4 - Playing Planning Poker
- Include all players on the development team (but less than 10 people overall):
- Database engineers
- Requirements analysts
- User interaction designers . . .
- Moderator (usually the product owner or analyst) reads the description and answers any questions
- Each estimator privately selects a card with their estimate
- All cards simultaneously turned over
- Repeat until converge
Slide 5 - Coming up with the plan
Slide 6 - Velocity
- Velocity is a measure of a team’s rate of progress.
- Velocity is calculated by summing the number of story points assigned to each user story that the team completed during the operation.
- We assume that the team will produce in future iterations at the rate of their past average velocity.
- “Yesterday’s weather”