Big picture planning with Agile

Question

I did some fairly thorough reading and searching through SO and didn't find anything on this topic, so hopefully I'm not creating a dupe. If this has been asked before I would appreciate a link.

I work for an enterprise development shop that is currently using a mostly waterfall process for software development projects. I've read through a lot of books and articles on Agile methodologies, and I can see how a lot of it could really improve our process. I can also envision how a lot of practices can be applied at the developer level, i.e. pair coding, shorter iterations, refactoring, TDD, etc. We are already doing a lot of that.

The big gap in my mind, and in the mind of the management in our organization, is how long-term planning would work in an Agile process. Before we can even start to work on a project, we need to have a budget approved by the internal customers that are paying for the software we are producing. How do we know what that budget should be if we don't do some fairly detailed requirements and estimation up front? Sure, our requirements and estimation and not perfect (and sometimes really off) but they are better than nothing.

A related question is how to judge the long term status of a project during construction. If a particular software product is worth a certain amount of dollars to the organization, how do they know whether we will be able to implement the product before we end up spending more than it is worth? I can see how Agile works when figuring out what work you can do during the next iteration, but how do you figure out an estimation of what the sum total of work will be to get to version 1.0 and whether or not you can have that done by fourth quarter of next year?

How does this strategic-level planning occur in an Agile shop? Do you just throw estimates against the initial vague user stories that you start from? Do you not do long term planning of this nature? Do you still have an up-front high-level requirements / design phase and then transition into an Agile process once the project is off the ground?

Thanks,

~ Justin

Answer 1

When doing strategic planning, internal customers tend to care more about features that requirements.

I tend to create a feature roadmap using a tool that supports traceability (I prefer Enterprise Architect by Sparx Systems but many tools will do). I review the desired features and the order they are needed in at the project sponsor level.

Then, I work with appropriate individuals (sometimes business experts, business analysts, or senior IT folks such as architects) to break down each feature into a set of high level requirements. I create traceability from the high level requirements to the features. At this point, the requirements are often at the level of "Add an ABC screen", "Add a DEF screen", "Create a background process to recompute XYZ" and so forth, without further details. At this point, I work with appropriate people to estimate the effort for each high level requirement based on whatever metrics are available (ranging from gut feelings to statistics on how long e.g. screens take on average to add). My modeling tool then sums up the total estimated effort for each Feature, which can then be presented to the project sponsors and placed in a project plan.

Then we start an iteration to address the first Feature or Feature Set. Each high level requirement is refined into detailed requirements ("Screen ABC needs a First Name field, max length 40, required" and so forth). Depending on project needs, we may re-estimate effort for the more detailed requirements and roll them up to the high level requirement they trace back to. More commonly, a developer will be assigned to develop Screen ABC, will enter his own estimate in the sprint planning tool, and that estimate will roll back to the original model. Since the requirements he's implementing (and estimated) trace to the high level requirements, which trace to the feature level, the plan is constantly updated as we get into each iteration.

It requires some discipline and effort to set this up, but it is well worth it.

Answer 2

Don't do projects where the value is so low, that it isn't obvious that you are going to get a reasonable ROI.

Don't try to create fake certainty where there is none. The big picture planning is, and should be vague.

An agile implementation proces allows the customer to steer and adapt. If you have an experienced team, a well-known and stable domain, no new technology or methodology, you know its velocity. This also puts limits on the size of a project you can estimate. Teams change regularly, technology changes every few years.

If a customer needs a detailed budget, she needs to provide user stories to an estimatable level. That means a lot of work has to be done up-front. All visible risk spikes have to be done. That work is only worthwhile when the requirements are sufficiently stable.

The level of detail Eric J. describes is totally unneccessary. That should be in the software and extracted from it, instead of specified on paper beforehand.

[edit] Having a list of stories that are not understood sufficiently by customer or developer can be interesting. You should not spend a lot of time on them, as their stability is low. Using cart sorting, you can get a quick idea of size and priority. Everywhere where there are large position differences, you have a potential risk. Asking all stakeholders to provide new stories can help you estimate completeness.

Answer 3

Big picture planning with pure Agile is extremely difficult. The first big problem is (as you've spotted) that pure Agile and forward planning (budgets, long-term timescales etc) fundamentally don't play well together.

If you are familiar with the project management triangle (scope, cost, timescale), Agile's focus is to fix cost and schedule and allow scope to be variable. In big organisations scope and timescale are often fixed (we need product X with these features by next quarter) and you then spend much of your time arguing the cost (i.e. number of developers) and often end up delivering late to boot because the timescale and permitted cost just were not enough.

This brings us onto the second issue - the change of mindset required to run pure Agile in a traditional company setting. The ideal advice would be get your organisation to buy into Agile wholesale and recognise that they can build a backlog of features but that not all of them may be delivered. However what is delivered will be high quality, on time and to a known cost. Changing to pure Agile can result in a serious shift of organisational thinking as Mike Cohen's book outlines expertly.

Unfortunately it's very very hard to change an entire organisation's thinking off the back of a single project so the third way is a compromise - you don't do pure Agile. What you do is something like RUP/Waterfall where you do some up front requirements analysis and do a bit of design and architecture work. Just enough to highlight risk areas and understand big-picture complexities. You then run an iteration "0".

Iteration 0 is proof of concept development for the high risk areas and to help understand key estimates and team performance. This may be a prototype that gets thrown away, it may be the foundations of your application's framework BUT the important point is to get a grounded feel for quality of estimates and likely velocity of the team etc. This gives you a foundation on which to build some plans and set a likely budget.

You can then run the dev work as normal Agile iterations, reaping the benefits of early user feedback and visibility etc. The iterative approach also helps provide regular milestones for you track against the plan, allow replanning points and earlier warning of budget over/under-runs. Use the estimates/actuals to date to re-work future plans as you go.