In the BABOK v3 4.1.6, estimation is listed as a elicitation technique and I seemed to struggle with that concept initially. As I was staring at this line item, I thought that I might as well build a narrative to help fulfill my daily word count writing goal. So here goes ...
Estimation is one of the most flawed concepts in project management, particularly in software development. You have a better chance of bumping into “Big Foot” at the local Starbucks than find a project with a set of estimates that reflect what actually happens. Overall, you just need to assume that along the way you will loose ground on some tasks, gain ground on others and it will all work out in the end. If you have a project manager that is actually maintaining a project schedule, estimation could be a way to trigger a discussion about a task. It can be an indicator that an issue that needs to be resolved requires team attention.
Regardless of how you feel about the cost-benefits of estimation, it seems to be a bit of a leap to include that as a method to "draw forth" requirements. I was prepared to write on and on about this anomaly until I remembered a time in which I used a planning poker session as a team building exercise. I could care less about what the estimates were that came out of that session. I just wanted to get a few silos in a room collaborating in a fun exercise and build a framework for ongoing shared understanding about the project requirements.
I was stunned by how many hidden requirements came out of those sessions. As people began to defend their too low or too high estimates, all kinds of goodies came spilling out. Not just requirements, but also business rules, unidentified stakeholders, risks and a wealth of overall tacit knowledge.
So yeah, I’m onboard with elicitation being included as an effective elicitation technique. Still not a big fan of estimates though, just saying (grin)!
© 2017 Dwayne Wright