Agile Estimating is great – but you still need good requirements

David Anderson talks about Agile Estimating.  I agree with all of this 100%.  However, how do you estimate a guess to begin with?  What exactly are we estimating?   My experience has shown that we do a poor job estimating from the start (techniques that David describes in his book and in his blog will help this make us do a better job) – however, what I’ve found is that we do an even worse job discovering, specifying and validating the requirements for which we place our estimates.  It’s like building a building on quicksand.  Yes, yes, yes – agile (I don’t use the term as a noun) techniques allow for changing requirements as you go through your lifecycle, however we still do a poor job with even our root requirements. 

Then there are issues around traceability and change control.  What happens when a requirement changes?  How does it affect what we’ve done?  Here is where Team System is going to play a role.  We need absolute transparency on our projects.  And to gain transparency, we need a foundation of traceability, clear accountability, and control.

There are many ways we can fix this problem; however, I won’t get into them today.  I would recommend that you all go and read David’s book “Agile Management for Software Engineering”.    Later, I’ll spend a bit more time equating how Team System will specifically address the common constraints in Software Engineering (again, all in David’s book).