Confluence Retirement

In an effort to consolidate USGS hosted Wikis, myUSGS’ Confluence service is scheduled for retirement on January 27th, 2023. The official USGS Wiki and collaboration space is now SharePoint. Please migrate existing spaces and content to the SharePoint platform and remove it from Confluence at your earliest convenience. If you need any additional information or have any concerns about this change, please contact Thank you for your prompt attention to this matter.
Skip to end of metadata
Go to start of metadata

Discussion Topic: 11/29/17


What approach has worked to best determine when a task will be completed on time, within scope, and within budget? Single point estimating? Three Point Estimating? Story Point Estimating? 50%-90% Estimating? Padding your initial thought by a factor of 2,4,8 estimating?

  • No labels


  1. Hans Vraga presented two projects, one example when estimating went well and another when estimating didn't go so well.  The take away from the example when estimated wasn't very accurate was to be careful estimating cost based on "face value" similarities to other applications. In other words, estimating a new project based on an old but seemingly similar project is usually full of gotcha's. It's really important to think through requirements before determining time estimates. 

    Other Highlights:

    • We also talked through philosophies like ITIL and AGILE and associated methods for time estimating.
    • We noted culture and funding structures and cycles have a big influence on the philosophies of project management and approaches to time estimation that we choose to employ.
    • Playing devils advocate we considered if time estimating is really all that important and maybe purely focusing on customer satisfaction and prioritization of task delivery is more effective. AGILE and ITIL both place a big emphasis on delivering customer value and creating customer satisfaction. In most cases, timelines are always changing, so estimating at the beginning of the project only is not a very effective tool for a project.  

    We had a good laugh at the TFB / NFC / 1 (Sprint) example here:

    And we created a new #projectmanagement slack channel!

  2. Was a great conversation - thanks all for the chance to present.

    I'm always game to chat about this topic - it's something that appears to be hard to do for the development community as a whole, and I've certainly not solved it for my group - so I'm always up for a chance at another perspective on how to tackle time estimation.