Take the 2-minute tour ×
Programmers Stack Exchange is a question and answer site for professional programmers interested in conceptual questions about software development. It's 100% free, no registration required.

Agile does not encourage a lot of up-front design. This is good from a requirements management and software development standpoint, and allows the project to adapt to changing business needs.

However, how does one do any long range planning of resources if you don't really know what you're going to build when you start? Oh sure, you have a conceptual model of what you're going to build, but you don't have any measurable detail from which to gague how many resources you will need to complete the project, or how much it will cost.

Does anyone have any suggestions on how to go about long range planning in an agile environment?

share|improve this question
1  
What are you looking for in terms of "long range planning of resources"? On an agile project, you shouldn't need/have specialized resources (or as I like to call them, people) :) –  Marcie Dec 27 '10 at 20:35
1  
Seriously? You're saying you don't need people to write software? –  Erik Funkenbusch Dec 27 '10 at 21:12
    
@MystereMan: I think Marcie means you don't need specialized people for certain tasks, as agile methods emphasize that people should be able to take over from each other. –  sleske Oct 3 '11 at 13:15

4 Answers 4

up vote 2 down vote accepted

I just pushed my organization to pilot an agile approach on one of our projects. It was a challenge for senior management because they need a projected budget and timeline before they can even get a project funded (it's a large enterprise-y company).

So, I did what I always do in that situation, make an educated guess. I looked at the scope we were assuming the project would entail, guessed at the development time of those items, added in some additional time for business analysts, DBAs, project manager, etc., added some padding, and called that the estimated budget. Note that this kind of "rough order of magnitude" estimation is done in my company before every waterfall project as well, so it was no different.

Then, as we started the agile project, and we got a sense of our velocity, we projected the end point of the project based on the velocity and the remaining story points, and found that we are coming in ahead of my original high-level estimates. But that is okay (and we expected it).

So I guess to generalize an answer, it depends on what you mean by "long range", and when you need these estimates. If you need them before the project starts, you can use my method. If you need them during the execution of a project, you can use the release planning concept that Matthew Kubicina mentions.

Also, I highly recommend Mike Cohn's Agile Estimation and Planning book which helps address this kind of stuff.

share|improve this answer

Agile has a concept of "Release Planning". The entire team gets together to plan out an upcoming release. I've done for up to 2-3 months in advance. This is usually done after the product owner has determined the "minimum viable product" and they know exactly what has to be done in order to release the product.

The team can take the known stories or epic story. An epic is large story or feature that has not yet been fully defined. Maybe something like "Allow international payments". Because this story or epic is so general, the estimates will be large and account for that. The team can do something called "t-shirt" sizes and give each epic a "small", "medium" or "large". This give the product owner some sense of the size of the stories in questions and allows the scrum master to make some estimates on what the actual release date will be.

The key is to start some where and continue to refine the story points or estimates as more information is know.

Here's a couple of links on release planning:

share|improve this answer
    
Ok, that works if you have a team and you want to figure out how long it will take to develop the product. That doesn't work if you don't have a team, and you need to figure out how big of a team you will need to build the product in x amount of time. –  Erik Funkenbusch Dec 27 '10 at 21:13
5  
OK. That's different then. You're not necessarily in the Agile methodology without a team yet. Agile states that only the people doing the work should be estimating the time it will take to complete the task. What I would suggest is getting some senior engineers or architects together and getting a rough sense of the timeline based on the product needs. You have to start somewhere. –  Matthew Kubicina Dec 27 '10 at 21:24

Try the Get Things Done methodology by David Allen; I remembered a passage of his book (the first/main one about GTD) where he says something like "being long term doesn't mean you have a lot of time to start doing it".

GTD helps you think in actionable terms, so you can program actual tasks that you can do or program to do in a system of your own. This is GTD in a nutshell: http://lifedev.net/gtd-cheatsheet/

GTD works for both life and work, and for shortest term to longest term as long as you keep thinking in actions, and not just things that worry you and/or your team. If you don't have a lot of time to read the book, get the audiobook, it is really worth it.

You can also try Scrum (and even combine with GTD)... you make a list of features, box 'em in a month of development and end up with a working version of the product.

Finally, I'd recommend you to read Rework by Jason Fried, where they talk a lot about prioritization and some informal project planning notions that are quite useful.

share|improve this answer

In agile, this is called inspect and adapt. Use history as your guide.

You need to know your speed before you can start making any assumption about how quick you can get to the goal. In other words, run through a couple of iterations to see how fast you are running and then use that information to make plans.

The answer to your question is that you must first gather data before trying to do any long range planning.

share|improve this answer

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

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