How to organize a 6-month project plan for agile?

Question

We have a charter to build a product in 6 months. I'll preface this by saying that my manager wants us to use waterfall, even though our development process is agile.

With that said, I have been asked to create a 6 month project plan that outlines milestone dates and a list of tasks & dates to monitor project progress. I've never done a detailed project plan for more than 2 months in Agile, so I need everyone's help :)

My thoughts:

Approach 1: List out all the project tasks and use guesstimates on work effort per task and present a linear path to completion. This is obviously risky since our estimates can be completely off and risk the timeline. I suppose we can de-risk by doubling our estimate #s?

Approach 2: Group tasks into sprints, and follow an 'x' week sprint cadence. Each sprint will have a breakdown of all the tasks we have to do until we get to 6 months. Unfortunately this still suffers risk of missing the deadline if our estimates our off...

Thoughts?

Answer 1

It doesn't matter how you organize the 6-month plan, if you are working in an agile way then it will inevitably be wrong.

The reasons for this are:

• Agile is about responding to change and responding to feedback. Any plan that details 6-months ahead cannot anticipate the feedback that will be received.
• All development projects include an element of discovery. This is typically a mixture of technical discovery and requirements discovery. Locking yourself into a 6-month plan ignores this.
• Agile teams typically work on a backlog that is in priority order. It is very unusual for priorities not to change over a 6-month period.
• Teams often struggle to estimate accurately for a two-week sprint, let alone for 6 months.

My advice would be to generate a roadmap rather than a plan and use vague references to timelines rather than specific days/weeks. Also, make it clear that the roadmap is subject to change based on the knowledge that will be gained as the project progresses.

Answer 2

Both approaches are far off being agile.

You can have a plan-driven big picture with an agile framework like Scrum for daily work. So you'll have a charter and a plan and baselines and a WBS with a dictionary. And when it comes to the activity-level, you are working with user stories. But again: this is not agile, this is plan-driven.

And an additional thought: in my eyes there's nothing wrong with choosing Waterfall as the weapon of choice when your project is in the lower left area of the Stacey matrix (and with a six months-schedule I asume it is).