Estimating Code (Stories)

I've worked in several "Agile" development teams over the years; from developer, to manager. Estimates are always one of the challenging things around software; both development's actual estimates (making them is very hard), as well as management's interpretation/understanding of them.

Some advice to developers:

Never utter the words "that is easy," because if you do, rest assured that everyone in the room has a radically different definition of "easy" (which is fluid in and of itself), and 3/4s of the room will expect the work to be done before the conversation is over. When I hear the words "that's a one-liner," I cringe. That "one-liner" inevitably takes hours of work. Try to consider the full spectrum of your process. When you make that "one-liner" change, what are the ramifications to your test infrastructure, for example? Whatever environment, or team setting, you are in, you need to understand it so you are able to fully estimate a Story.

Too often developers have tunnel vision into their specific area, and we lose sight of the bigger picture. Story/work estimation is part of a bigger picture, and developers need to be aware of that when we're estimating things.

Some advice to managers ("managers," product managers, project managers, whatever):

If you ever hear the words "that is easy" or "that's a one-liner," take it with a grain of salt. Gently prod to vet the surrounding estimates. The coding itself, may indeed be an "easy" "one-liner," but the ramifications to tests that have been written, or to QA, or to operations/production, or deployment, or system administration, may be huge.

Everyone on the team needs to have an understanding of their process and software life cycle in order to have a sense of what code is going to do downstream. There are plenty of "one-liners" that can bring your software to it's knees for weeks.

Software construction doesn't work well when the "customer" (Product Management, CEO, contracting client, yourself, whomever) is disconnected from the process. That disconnect can be organizational, emotional, intellectual, or otherwise. If you're building software and you feel disconnected from your customer, fix it. If you're having software built for you and you feel disconnected from development, fix it.