Forecasting In An Agile Environment

One of the most common issues at Agile shops is planning and forecasting. Agile shops aren’t like waterfall shops where you plan a 9 month release in advance. In a waterfall shop, it’s very clear what you’re planning to release in 9 months (which is a bit untrue because I’ve never worked at a waterfall shop that actually forecasted accurately but at least they had a forecast!) Which means that product managers at an Agile shop are unable to plan out releases or build a detailed roadmap.

What I’m about to describe is a way to solve this problem through a bit of spreadsheet magic.

(Note – If you want to see an example of what I’m about to discuss, check out this Google spreadsheet)

First, Write Your PRD

PRD’s are your bread and butter. They describe the project you intend to build, the business problem it will solve and the functionality you intend to deliver. Every project that involves more than 1 or 2 stories should have a PRD. No exceptions! Yah, I know, you’re an agile shop and you just work with individual stories. Sorry, being agile is no excuse for doing a poor job as a product manager. Your devs might worry about individual stories but you need to worry about the project (or epic) as a whole. For that, you need a PRD.

Second, Write Your Place Holder Stories

Each PRD should include the stories you’re going to deliver. These need to be broken up into the smallest possible chunk of functionality that still provides value. So if you’re doing a project that will allow users to authenticate through a social channel then you need to have one story that says “User can authenticate through Facebook”, another for Twitter, another for Google+ auth, another for “user sees error message if they try to authenticate a channel already used by another user” and so on. Break it down! This is your job as a PM and it will make the devs job a lot easier.  Don’t just write a single story called “User needs to authenticate through social channels”.  That’s pointless.  You’ve told the devs nothing about what they need to build, you’ve told your stakeholders nothing about what you intend to deliver and you’ve made your forecasting job impossible.

Third, figure out your velocity

Velocity is a measure of how many stories you can complete each week (or whatever your release cycle is). Some companies measure velocity in points and each story could have a different point value depending on complexity, but the idea is still the same. You’re trying to measure how many units of productivity your dev team can produce in a given time period. Other companies will choose not to include bugs in velocity calculation or to exclude chores. That’s fine, I don’t really care what specific system you use as long as you use it consistently.

Fourth, figure out the average value of a story

Remember those units of productivity you measured in step 3? Now you need to figure out how many units of productivity an average story is. If you’re not pointing stories then this is easy, it’s 1. If you are pointing stories, just look at your last 100 stories and come up with the average point value.

So what do we have?

  1. A PRD that represents a project
  2. The number of stories in that PRD
  3. The average number of units of productivity your team can produce in a given release cycle.
  4. The average number of units of productivity an average story costs

Multiply 2 by 4 and you have the total value of this project. Divide by 3 and you have the number of release cycles this project will take. Now do this for every project you have in your queue and you can build a really accurate roadmap.

Pro Tips!

  • Estimate velocity by engineer (or by pair if you’re a paired development shop) – Doing this will let you accurately factor in things like hiring. Just make number of devs a variable which is multiplied by velocity per dev to get total velocity.
  • Split projects into done, in progress and remaining stories – This will give you a good feel for when a product will be complete and how much progress you’re making.


  • How should I use this model with my ENG dept? First, let me answer how you SHOULDN’T use it. You shouldn’t use it as a stick to hold over their head and say “this is what you guys promised me! Where is it?!?” That’s a very quick way to make enemies which is something you don’t want in the ENG dept. You should make sure they see this as their shield. This is the tool that will let them explain to the rest of the executive team why it’s impossible to just “add a small feature that the CEO wants” or why it’s better to start with a small project as opposed to writing every possible story that a customer ever requested. This is their tool to show what happens when you don’t pay off tech debt and velocity per week starts dropping because it’s harder to write code. This is their tool to show people what they could do if they could get more engineers. For a smart head of ENG, this spreadsheet should be their best friend.
  • How should I use this with management? I would share all of this with management and be very open about what this means. They need to understand what features are in the queue and when they will be delivered. They also need to understand what levers they have to make things show up quicker.
  • Why do you have a 20% buffer built into this? Because stuff happens. You have a week with a lot of bugs, you have a minor unexpected feature request that you just HAVE to deliver this week, you have an engineer out on vacation. That buffer is your protection against the unexpected. Be very careful about eliminating it.
  • Can I use this model? Of course. The only credit I want is that you call it “The Wave Model”
  • Why wave model? What wave is it measuring? No wave. It’s just that my name, Gal, means Wave in Hebrew and I have a huge ego that I am trying to make less than obvious so I didn’t want to call this the “Gal Model”.

Note – Copy of spreadsheet is provided by permission from my current employer, SocialChorus – SocialChorus website

SocialChorus® powers tens of thousands of brand advocates – employees, consumers and bloggers – to experience, create and share authentic content about brands they love. We call this new marketing category Advocate Marketing.

Our award-winning Advocate Experience™ solution makes Advocate Marketing performance easy. We combine a comprehensive SaaS platform with a dedicated, expert team and best practices to deliver measurable social engagement with millions of people every month.

Leaders in every industry, including consumer packaged goods, retail, technology, telecommunications, travel, automotive and financial services have chosen SocialChorus, the recognized leader in Advocate Marketing.