Forecasting timelines for Stakeholders

There has been a lot of great movement towards agile software development over the last decade or so. However, there are still a few struggles or gaps you’ll find in most organization today that claim to be agile. That is with the dilemma of how to forecast updated timelines to the customer and or stakeholders.

Product t-shirt sizing chunks of work, or forecasting based on a well-groomed backlog ?

If you ask a typical agile dev team member how they would handle providing timelines of work to be completed, you might be surprised by the answer. They might just not care about what we may or might not do six months to a year from now but more about continuously delivering what the customer wants now:

Project Plan Gantt charts and Product Roadmaps with far out timelines and Roadmaps are the old way of doing things. A constant feedback loop with the customer is the new way to do things in the agile software development world.

This mentality is actually on the right track, but it doesn’t consider everything that the rest of the business side has to do. There will always be those (internal or external) that want to put a timeline or price to the period of time taken or needed to complete something. I know what you’re thinking, this is very waterfall and you’d mostly be right. The fact of the matter is, although the tech side has really come around to the agile mentality, the business side isn’t quite there yet. Also, not all customers are fully sure what it really means to be agile, so hence the million dollar question, what is the best way for forecasting timelines in the Agile software development world?

Spotify says it really well in this short video (start at minute 5:14):

You’ll notice they say that Innovation is greater than Predictability and that 100% Predictability is 0% Innovation. Also, they say that for certain scenarios like partner integration and marketing events we can use standard agile planning techniques like forecasting based off teams average velocity and burn up charts. They do mention though that if they have to promise a date they wait until the feature is proven and close to ready.

Another great video created by Henrik Kniberg (start at minute 11:29):

In Henrik’s video it talks about using burnup charts to show how many stories have been completed by the team(s) over a period of time. If you have a well groomed backlog, you use the previous amount of stories (by number or points) completed over time, and look at your backlog to see how many for that Epic or Feature remain to give an estimate of when the work would be completed.

The links I provided above are really great, but don’t really cover how most Project Managers or Product Managers realistically are tracking milestones today. I see a lot of high level gantt charts or beautifully created roadmaps that are used to provide updates to high level management for all sorts of reasons. In my opinion and experience, as long as these are kept at a high level and not strictly forced upon the dev teams but used more for high level comms for the project(s), there really isn’t a problem. It’s when these are used to micro manage the dev teams to a hard timeline that it gets a bit worrisome.

I have seen the use of t-shirt size estimations used in a positive way to provide these high level forecasting to customers and or stakeholders. Typically I’ve seen this done by having the product manager invite the dev leads into a monthly meeting to estimate how long certain work would take, put into values of small (1-2 weeks), medium, large (4-6 weeks) or extra large (using t-shirt sizes).

In any environment, collaboration is very important, so as long as any of the above mentioned techniques provides value to the team, customers or stakeholders and is done in the right way you’ll be heading down the road to success.