Our team has been asked to represent our development efforts in a project plan. No one is unhappy with our work or questioning our ability to deliver, we are just participating in an IT cattle call for project plans. Trouble is we are an agile team and haven't thought about our work in terms of a formal project plan.

While we have a general idea of what we are working on next we aren't 100% sure until we plan an iteration. Until now our team has largely operated in a vacuum and has not been required to present our methodology or metrics to outside parties. We follow most of the practices espoused in Extreme Programming.

We hold quarterly planning meetings to have a general idea of the stories we are going to work on for a quarter. That said, our stories are documented on 3x5 cards and are only estimated at the beginning of the iteration in which they are going to be worked. After estimation we document the story in Team Foundation Sever. During an iteration, we attach code to stories and mark stories as completed once finished. From this data we are able to generate burn down and velocity charts. Most importantly we know our average velocity for an iteration keeping us from biting off more than we can chew.

I am not looking to modify the way we do development but want to present our development activities in a report that someone only familiar with waterfall will understand. In What Does an Agile Project Plan Look Like, Kent McDonald does a good job laying out the differences between agile and waterfall project plans. He specifies the differences in consumable bullets:

  • An agile project plan is feature based
  • An Agile Project Plan is organized into iterations
  • An Agile Project Plan has different levels of detail depending on the time frame
  • An Agile Project Plan is owned by the Team

Being able to explain the differences is great, but how best to present the data?

3 Answers 3


Show them the half-arsed agile manifesto.

It definitely tells you what the Agile system is all about by comparing it to waterfall methods:

Individuals and interactions over processes and tools
and we have mandatory processes and tools to control how those individuals (we prefer the term ‘resources’) interact

Working software over comprehensive documentation
as long as that software is comprehensively documented

Customer collaboration over contract negotiation
within the boundaries of strict contracts, of course, and subject to rigorous change control

Responding to change over following a plan
provided a detailed plan is in place to respond to the change, and it is followed precisely


I had to do this, once. The Team wanted to do Agile, the Client wanted (and understood Agile), a external 3rd Party (call them "Auditors"), wanted to see Waterfall reports.

An important reason why we could Lie was because the 3rd Party didn't actually care, they just wanted to check boxes. If the Client was happy and the Team was happy the "Auditors" would hardly go back and look at the reports we gave them, prior to checking off the final boxes.

Don't do this if the 3rd Party matters and ACTUALLY cares that you are using waterfall. If the Auditors know you are being Agile, and just haven't updated their paperwork to support you -- then you can Lie.

What do you do? Lie, but white lie.

  • Rephrase Features, as requirement "Must have Feature".
  • Your work is in Iterations, iterations generally go over X weeks, a waterfall plan likes to see things generally in Weeks, so no big issue. You can label the end of each iteration as a Milestone. Milestones are waterfall. Iterations tend to have a theme (or an associated Epic) so you can stick the theme/epic title on the the milestone (eg. 21/11 Have GUI complete.)
  • Calculate your velocity (from your burn down/up charts) and work out how much time a Story Point, on average, represents (at least at your current velocity), this will give you task durations. Often wildy inaccurate ones, but they will be meaningful to an extent.
  • Your plan has different level of detail depending on timeframe - basically the same for waterfall. Possible differer a waterfall plan has different detail depending on Audience.
  • An Agile plan is owned by the Team. A waterfall plan is owned by the Project Manager. You've provably got a Project Manager already, and they are probably doing this translation. They should take ownership of this translated document and shield the team from the flack that might come raining down upon them because of it. It is the job of a Agile or Waterfall Project Manager to shield the team from distractions that will stop them from working.

  • Sure you don't really know what you are doing next iteration, but you do know roughly what you are doing. You've got a feel for it, and a rougher still the Iteration after. (I've heard this called the Iteration Radar). Lie and say you do. and when lie through your teeth about story card that isn't on your Iteration Radar, and just put it in somewhere. Hope you don't have to submit too many updates on the project plan, or they will notice that you haven't done what you said you will.

Basically this is a pain. Translation will be many hours of work. If you have to do it a lot, automate it.


The first question to ask is what does the business actually want? Some business are perfectly happy seeing agile sprints represented / broken down into a Gantt chart. It may make no sense to anyone that actually understands the sprints and may change regularly but it is familiar to the people asking for it. Then along with the Gantt chart, present the burndown, etc.

We've been through something similar and eventually (if Agile is working) it will sell itself (if it doesn't then why are you doing it?). People begin to understand "effort" and that a certain team is able to "burn down" 40 effort points in a 2 week sprint and are actually pretty good on average of estimating those effort points. Once they see the benefits for them, they'll sell the process to the rest of the business for you. But the main point is that you can never, ever force it onto somebody as they'll just fight back.

  • 1
    I totally agree that agile cannot be forced upon anyone. Either you want to or you don't. That said it just seems odd to present a GNATT chart for a two week iteration, but I am all about bringing other people into the fold.
    – ahsteele
    Apr 14, 2011 at 3:39
  • Good luck with your efforts, hopefully you can get people on board. Apr 15, 2011 at 10:10

Not the answer you're looking for? Browse other questions tagged or ask your own question.