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…

11 thoughts on “Up-front planning and Agile

  1. The notions of #NoEstimating have failed to connect with writing software for money.

    The suggestion by some that Agile equates to #NoPlanning is of course more failure to even read the basics of Agile. It’s not called “The Planning Game,” or the “Planning Session” for nothing.

    It seems to have come to the point, that any suggestion of being a good steward of the customers money is somehow restricting of creativity. May be at the end of rational thought here.

    1. Glen, to me it strikes a bit odd that planning and being prepared is somehow prevents creativity.

      It’s knowing your domain and providing your customers info they don’t have. So they can know better how to use their $.

  2. Great! I agree.
    Although, I think the most interesting part is the “Etc etc”. Please continue 🙂 When do you have the complete list to make an estimate not be wrong? Don’t focus on having a complete list, focus on becoming better at responding to change. Both you and your customers.

    And I think you miss the point. You say: “And the exact questions here are not the point – the point is that if you plan for these”. Well, I disagree. That’s exactly the point. The more questions you put on this list the more “unrough” the estimate will be. But the more questions you put in the list the more “waterfally” it becomes. See the dilemma?

    So, the basic questions become: how rough estimate can a customer accept to make a good decision? 2-4 weeks? No problem. 2-4 years. No way.

    1. Henrik, I don’t think there is such thing as “complete list”. It depends on situation and the needed granularity. IMO, roughly, you shouldn’t get much deeper than that. In that particular scenario.

      It’s impossible to say when too much detail up-front is too much. It’s grey and fuzzy. This is the key to our profession — knowing then enough is enough.

      Although I can be quite certain that if you skip this step altogether — that’s bad. That’s not “agile”.

      1. So true. And today (and most days before that) I think we focus too much on estimates. And it hasn’t made things better. Drop the focus on them, focus on other things.
        #NoEstimates is actually all about that: What is enough?
        Sometimes 0% is enough 🙂

  3. And to continue. The only real question you need is: “How can this be broken down so you have something that contributes to the learning you/we seek”. I.e “You/we need a capability, what’s the minimum thing we can do to prove the capability will give the advantage you seek?” Might not even be sw, actually.
    When we’ve/you’ve proven that, continue/iterate.

    1. Yes, this is roughly how it should continue. Or would continue. Put think about our pooh customers. They just want to have some kind of idea. They might think an effort is 2 years, when actually it is 2 months. And they deserve to know what are the high level assumptions that affect that work effort estimate in their situations.

      1. Totally agree. If we stay at estimates around ” This is more like 2 months than 2 years.” we’re actually in #NoEstimates I’d say.

  4. …thus, if you focus a lot on “questions/list to make estimates more credible” I think you’re focusing on the wrong things.
    That doesn’t mean you shouldn’t focus at all. Planning is great.
    The basic concept of #NoEstimates really.

    1. The art is to know what is enough. And what too much.

      I think I have rough gut feeling about smallish projects.

      I don’t know a thing about multi-million programs that Glen is running, that I have to say.

Leave a Reply

Your email address will not be published. Required fields are marked *