I want the world in 6 days!

DDD is a reality of every business but should not be because it creates false expectations, unnecessary pressure and panic.

In this article I discuss the perils of using DDD when estimating delivery dates or the scope of work to be done for a given date. I also propose a much better, alternative approach that will prevent panic from setting in close to deadline dates and make your office a happier place.

What is DDD?

DDD is typically characterised by two different kinds of request from the business:

• “I want a product with this set of features on/by this date”
  i.e. “I want the world delivered in 6 days”, or

• “Here’s what I want – what date can I have it by?”
  i.e. “I want the world – how many days can I expect it in?”

Two very common requests, both equally as impossible to meet expectations (unless you’re God, and even He had to cut corners to get the world finished in 6 days).

Problems with DDD

Let’s look at each of these two types of request in turn and why they are problematic:

• “I want all these features by March 29th”
  • Ideas will evolve and features will be added
  • A new idea will automatically feel like a high priority, but you still want the other stuff
  • There is pressure to make your estimate fit to meet the date rather than represent the reality of the time and effort involved
  • Creates panic when the date approaches
  • We don’t really know our resource capacity for the duration of the project
• “What date can I have all these features?”
  • Estimating an exact, firm delivery date is neither practical nor possible
  • Estimating is inherently imprecise (the clue is in the word)
  • Attempting precise estimates creates false expectations and pressure (“we’re getting our product on March 29th, woo hoo!”)
  • We only know the current resource situation, not the future

Not to mention….

• People get sick, go on holiday, leave, need to train new people etc.
• So even if you could make a precise estimate, and the feature set never changed, the delivery date will still be wrong because the resource pool is highly unlikely to stay consistent over a period of months
• Bottom line – no project will EVER deliver an upfront set of features on a set date because
  • Feature list and priorities are guaranteed to change
  • Estimates are effectively guesses yet business treats them as set in stone

OK, but I still need to know when I’m getting my product, right?

Of course, but let’s make realistic estimates together. When estimating, you need to consider accuracy over precision. This statement often raises eyebrows, but there is a clear difference between the two.

If someone asks “how tall is that building”, what is your best chance of being accurate? You think it’s around 450 feet, but being so precise means you are wrong if the building is actually 500 feet.

A far more sensible approach, given that the exact size of big things is extremely difficult to estimate, is to try and be accurate instead. By saying “400-500 feet”, your statement has turned out to be accurate because you have given yourself margin for error. This is so often overlooked in estimation but is so crucial.

Simply put, accuracy is far better than precision when estimating, and your accuracy only improves as the project progresses. That’s not to say that being accurate is easy, especially early on in a project. It isn’t – accuracy is still hard, but it is far easier than precision and does not create false expectations.

We inherently know attempting precise estimates is folly

This talk of accuracy over precision may all sound like word trickery or even stating the bleedin’ obvious. However, we use this technique outside of the realm of software delivery estimates daily. We mitigate risk with estimates all the time in everyday life because we know precision sets us up for a fall.

If you say to your friend “I’ll be at the pub around 5ish” or “I’ll be there some time shortly after 5″ – your friend knows you may be there somewhere between 4.45 and 5.30 and are fine whenever you show up.

However, if you say “I’ll be there at 5″ and you show up at 5.20, you are late and your friend will be pissed off.

OK, but how does that apply in software delivery?

Exactly the same principle applies in business. If you say you will deliver some time in March and you deliver on March 29th, you have delivered on time as promised. If, however, you say you will deliver on March 12th and end up delivering on March 29th, you have delivered 17 days late.

Here is what needs to happen when planning development of a software product:

• Product Owner (PO) will define an initial set of features
• PO sits down with team to estimate how long this set of features will take, splitting them into 2 or 3 releases to improve accuracy (smaller things or smaller sets of things are easier to apply time estimates to)
• Provide an estimate similar to the following: “This set of features is likely to take 1-2 months of elapsed time”
• This is a perfectly reasonable estimate and is far more likely to be accurate than saying it will take “two iterations” or “4 weeks”
• DO NOT fall into the trap of making a precise estimate

But what if I have an important date to aim for?

“That’s all very well”, your PO says, “but I want to deliver my awesome new baseball game in time for the start of the MLB season on April 1st”.

That’s fine, but what we can’t do is promise all the features he wants now on that date. What we need to do in this instance is to estimate what percentage of the initial feature set is likely to be delivered around that date assuming the feature set doesn’t change:

“We estimate that the top 80-90% of these initial features can be delivered around the first week of April”

If and when the priorities change and/or new features are added, the PO and team then need to negotiate which of the initially agreed features will drop out of version 1.0.

Here are some other crucial aspects of getting your software when you want it:

• Listen to the technical team!
  • You will mitigate the risk of delivering late by delaying technically difficult features until you have a working product
• Keep a consistent team
  • If teams stay together they become more close-knit and are far more likely to become increasingly efficient and predictable in terms of how much work can be delivered in an iteration
• Avoid surprises
  • Maintain close communication with the team so risks become visible early
  • Mitigate any risks the team raises as quickly as possible and you will get a product on the date you want, but be realistic about the feature set

Reality of product evolution

The result of all this is a truism that many businesses will not admit: The product you end up with will not be the one you first envisaged – guaranteed!

The important thing to remember is: that’s fine! Iterative development allows us to change feature priorities as we go along and add new features. The PO should focus priorities on the core product features, then iterate over the working software to improve it.

But, the PO and the business also need to understand that:

• The product will evolve with new ideas and market changes
• Some of the initial features will not be in version 1.0

In summary…

• If possible, do not focus on dates at all
• Focus on creating working software and improving it iteratively
• If you must focus on a date then aim for accurate estimates rather than precise and make sure the release backlog is regularly groomed by the Product Owner (i.e. the list of features scheduled for version 1.0, which will change often, is in priority order and up-to-date)
• Scope and time should be negotiable, whereas quality is fixed
  • If there is an immovable date, the scope of features delivered has to be negotiable
  • If there is an immovable set of features then the delivery date has to be negotiable
• Pressure of unrealistic dates is counter-productive and de-motivating