Planning 2 - Estimation Mechanics

AgileEstimationPlanning
1.0x

Planning 2 - Estimation Mechanics

Created 3 years ago

Duration 0:04:42
lesson view count 502
Select the file type you wish to download
Slide Content
  1. Planning 2:Estimation Mechanics

    Slide 1 - Planning 2:Estimation Mechanics

    • Emerson Murphy-Hill
    • Creative Commons Attribution 4.0 License.
    • Material Produced by NCSU Software Engineering Faculty.
  2. Deriving an estimate for a user story

    Slide 2 - Deriving an estimate for a user story

    • Analogy
    • 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
    • Disaggregation
    • 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
  3. Planning Poker(http://planningpoker.com)

    Slide 3 - Planning Poker(http://planningpoker.com)

  4. Playing Planning Poker

    Slide 4 - Playing Planning Poker

    • Include all players on the development team (but less than 10 people overall):
    • Programmers
    • Testers
    • 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
    • Re-estimate
    • Repeat until converge
  5. Coming up with the plan

    Slide 5 - Coming up with the plan

    • Desired
    • Features
  6. Velocity

    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”
    • http://agilesoftwaredevelopment.com/blog/pbielicki/predicting-team-velocity-yesterday-weather-method