It happens often, you’re working with a client and they are excited for a delivery of a new app or feature and are asking THE question — when will it be delivered. For clients coming from Waterfall-based scheduling or general common sense logic – it appears as a fair question. They paid you and now are looking for a delivery date. But I posit that web application development is not like Amazon Prime when you click “Buy Now” and an arrive by date appears. Rather consider, in Agile development, you the client have bought a car – you can go anywhere as fast as the car will go. If you buy a Volvo versus a Lambo – your speed or, in agile terms, your velocity will be different. As the client, where you go and changes in direction are all up to you – but so is how long it takes that car to reach its destination. Such is Agile development; your pizza team is ready to go at a certain velocity. Where it goes and how long it takes to get there is up to you.

The customer’s gut feeling is to want a delivery date and sometimes their insistence is rooted in “well I need a date for upper management” – this is a common point where we, as Agile development firms, need to pause, push back and help customers rethink how they are approaching development. Gone are the days where one could easily and accurately guess when a new application will be released – many have tried and failed. Rather than attempting to look into a crystal ball and divining a date for your customers like a modern-day Miss Cleo, we should help educate them on how forecasting deliveries in Agile works.

When a customer brings DAE on board, they are buying capacity. Capacity to build an application with a given velocity. If they hire five of our pizza teams, they get roughly X velocity per team versus if they just buy one.  Agile prescribes that a given team, once formed and organized, can produce at X velocity. That velocity is an average of that team’s last three sprints.  Therefore, paying for a pre-designed team is more valuable to a customer than a single developer – a pre-made team that already knows how to work together and has a known velocity can help a customer forecast.

Now that we have a given velocity, the customer then needs to look at the app capabilities they want – are they asking for 1,000 or 10,000 stories app? Our team sits down with the customer to develop capabilities and high-level road maps – those than can help generate epics, and we can start generating draft stories with estimated points. All this will help a customer with expectations and better understand where and how their application will be delivered.

With all this, once a velocity and forecast have been established, they do not remain static. It will change and require monitoring – when stories or epic scope change, reevaluate your forecast. When your team has any changes, reevaluate your forecast. Hell, when the weather changes reevaluate your forecast. Back to the car analogy, if you have added more passengers or changed how many stops you make, your velocity will change, so it needs to be tracked. Such is an Agile development team – once finely tuned, they can deliver great things, but constant monitoring and maintenance are required to keep going as smoothly as possible.

~Gabriel Alix