Monthly Archives: July 2014

#NoEstimates confusion

So you’re always late. Your friends ask when are you coming, and you always give way too optimistic answer. Or something else happens. In any case —  you’re always late. Simply put, there are two possible ways to handle the issue:

  1. Find a solution: You try to be better in estimating your arrival. You take into consideration that traffic affects your travel time. You remember that putting your clothes on takes longer in winter. You add marginals to your “arrival estimates”. This way you are better estimating your time consumption, and as a consequence, you’re more often on time.
  2. Change the problem: You change the setting so that either you don’t have to give an “arrival estimate” or it doesn’t matter that much if you’re late. For example, instead of meeting outside of restaurant before going in, you agree to meet in a bar nearby. So if you’re late, your friends can just have one more aperitif, no big deal. Maybe your dinner party starts with a flexible cocktail party period instead of punctual time. So we change the problem from “How to be on time?” to “How to change things so that my friends don’t need to rely on estimates so much?”

The way I see it , currently #NoEstimates is about option #2 — changing the business so that you lessen the need to estimate.  If you stay within #1, the solution space, I agree that #NoEstimates makes no sense. If someone asks “how long is it going to take?”, you need to estimate to answer, there is simply no way around it!

The key questions here are “How do I change my way of doing business so that I don’t need to ask ‘how much? when?’ so often, or if I do, it is for shorter period of time? How do I deliver value sooner? How do I validate my concept ASAP?”

One small addition: in real life, #1 and #2 are not mutually exclusive. You can, and should, usually do both.


Up-front planning and Agile

This post was triggered by this conversation I recently had in Twitter with Henrik Ebbeskog. Reading that before continuing on this one may help you understand better.

So let’s assume a scenario. A client wants to set up a web shop(*), and would like to hear your rough estimate how much effort would it require. The client just wants a ball-park, so we’re not signing contracts here. Here’s what you should  take into account before giving your answer:

  • High availability requirements, how many users do you expect? Simultaneous users?
  • Different user personas
  • SLA requirements
  • DB backup requirements
  • User support requirements, do you perhaps need a live help line?
  • External interfaces, do you need to interface with a bank payment interface perhaps?
  • What markets are you targeting, maybe countries that write from right to left?
  • Etc etc

You probably can come up with more, and adjust these to your own domain. And the exact questions here are not the point — the point is that if you plan for these, and take these into account, you can base your estimate onto these. “It’s roughly 2-4 weeks IF just a single server, no user support, no redundancy in servers, we offer 9-17 support weekdays only, and it contains more or less these features”

And here comes the catch: this doesn’t mean you’re setting these in stone. This isn’t Big Design Up Front. This isn’t waterfall and forgetting about Agile values like responding to change. This is planning, being prepared, listing your assumptions explicitly and asking your customer questions she didn’t think of.

Agile doesn’t equate to #NoPlanning.

*) Sheez, always a web shop as an example. I need to expand my imagination…