Agile Project Planning Tips
Home  |  Articles  |  Books  |  IT Surveys  |  Podcasts  |  Contact Us  |  Announcements  |  Site Map

My goal with this article is to share good project planning practices which I find to work well in practice.  A fundamental difference between agile project planning and traditional project planning is that agile project planning is very collaborative in nature: the team is responsible for planning, not just the project manager.  In this article I discuss: Scheduling Tips Iterations Estimating Tips People Management Tips Agile Metrics Tips Some Humor (Perhaps) Training

1. Scheduling Tips

1. You can accurately plan in detail only for nearby tasks.  Notice how in Figure 1 I only planned for iterations 1 & 2 in detail, I can schedule in detail several weeks ahead but not several months, and only did a high-level scheduling for future iterations.  Figure 2 shows how my schedule has evolved by the fifth iteration, I'm doing just in time (JIT) planning. At the end of the project I have an accurate, detailed plan, as shown in Figure 3.
2. Question the use of Gantt charts.  Although I show Gantt charts in Figures 1 to 3 there seems to be growing evidence that Gantt charts have little value on agile projects (although my experience is that a high-level Gantt chart such as Figure 1 does provide value to help you think through major dependencies, just don't go any further than that).  My 2007 Agile Adoption Survey showed that Gantt charts are the least valuable work product on agile projects whereas iteration task lists were one of the most valuable.  I like to say that "Friends don't let other friends use Microsoft Project".
3. The people doing the work must be actively involved in scheduling.  They're motivated to get it right, they have skills to understand the dependencies, and they need to accept the schedule.
4. People should choose their work, they shouldn't be assigned it.  It is quite common on agile projects for the team to do the planning, not just the manager/coach.  Project planning is so important that we want to get it right.
5. Organize the project into short iterations.  The only true measure of progress on a software development project is the delivery of working software.  By working in sort iterations, 1 to 4 weeks is common, and by delivering working software each iteration you provide concrete evidence that your project team is progressing.  This provides greater visibility into the true status of a project than does documentation-based earned value measures and improves your ability to effectively govern IT projects as well.
6. Take a requirement-based approach.  Agilists typically schedule the development of requirements (user stories, features, use cases, ...) into iterations as the line items, not tasks such as design, test, ....  For example, the line items of iteration 5 might be "Implement Search for Books", "Implement Search for DVDs", "Implement Process Mastercard Payment", and "Implement Capture Different Billing and Shipping Addresses" for an online e-commerce system.  These line items would stretch the length of the iteration, I would trust the team to schedule the actual work appropriately and wouldn't go into any more detail in the project schedule.
7. Schedule tasks involving external groups.  When a task involves an external group, perhaps you want to demo your system to some project stakeholders or deploy a testable version into your QA/test environment then you should consider including the task on your schedule as a reminder to coordinate with those groups.
8. Remember to include training.  Training usually occurs at the beginning of a project so that team members can learn the fundamentals of any new skills that they'll need on the project.  Training will also occur throughout the project, particularly for new staff, but the majority typically happens at the start.  Remember to plan for it.
9. Choose an approach which reflects your environment.  The article Comparing Approaches to Scheduling and Estimating Software Development Projects provides insight into your options.

Figure 1.  The schedule at iteration one.

Figure 2. The schedule at iteration five.

Figure 3. The schedule at  project end.

1.1 Iterations

Many organizations struggle with the concept of iterations.  This advice should help:

Shorter is better.  An iteration shouldn't be any more than 4 weeks in length, otherwise you're likely to slip into a mini-waterfall style of development. I prefer either one or two weeks in length. This keeps the delivery pace of the project nice and steady because you deliver some new functionality on a regular basis. Start with an uncomfortable length.  When you're transitioning a traditional organization to an evolutionary (iterative and incremental) approach to development, try to identify the length at which they think they're comfortable (e.g. 8 weeks) then remove a week or two (e.g. start with iterations of 6 weeks) to force them to become less bureaucratic. Do a couple of iterations like this, then start reducing the iteration length until you're down to something reasonable (e.g. less than 4 weeks). Ignore the calendar.  If your iteration is one week in length, run it from Wednesday to Tuesday. Iterations which run Monday to Friday typically suffer from "Weekend-itis" where your focus and energy is reduced dramatically on Friday because it's the end of the iteration and the end of the week. This is effectively a double whammy to your productivity. Produce something useful. Fundamentally, an iteration should be just long enough so that you can get something useful done.  Some teams have iterations that are one day in length. Have as many iterations as you need. Requirements change, which means the length of time you need to implement the system should change to reflect this. You can still have a firm delivery date.  If you need to have a firm delivery date, then simply set one and deliver at that time. Keep doing development iterations until you get to the point where you need to deliver the system. If you continually implement the highest-priority requirements, see Agile Requirements Change Management, then what you deliver will be the highest value possible.

2. Estimating Tips

The best estimates are:

1. Done for smaller, rather than larger, items.  It's easier to estimate work that will take one day than it is to estimate something that will take one month.
2. Done by the people doing the work.  They're more motivated to get it right, after all.  Initially developers may not be very good at estimating, but they very quickly pick up the skills if you give them a chance.  The best estimates are "bottom up", not top down.
3. Done by someone who has done the work before.  They know what they're talking about.
4. Presented as a range.  The longer away something is the greater the range your estimate will need to be.  For example, if I'm estimating the cost of a six month project at the beginning, I may have a range of +/- 20%.  If I'm one month away from delivery, my range may be +/- 3%.
5. Updated throughout the project.  As your actuals come in, you have a better idea as to what the cost will actually be.
6. Choose an approach which reflects your environment.  The article Comparing Approaches to Scheduling and Estimating Software Development Projects provides insight into your options.
7. Beware professional estimators.  Professional estimators, perhaps people with COCOMO II or Function/Feature Point counting skills, sound like they have a good approach.  In practice professional estimators only seem to produce estimates whose only "benefit" is that they're backed up by a lot of elaborate work.  Management seems to think that these estimates are very good, and with enough effort they often are, but these techniques prove to be a very expensive way of producing estimates.  My advice is to keep things simple and instead follow the tips listed above.

In The Dire Consequences of Fixed-Price IT Projects I described the questionable software development practices motivated by the decision to develop an accurate up-front estimate.  To develop such an estimate you need to understand the requirements which you are supposed to implement and the architecture which you are going to build to.  The desire for greater accuracy increases the need for more detailed information, which in turn motivates you to adopt:

1. A big requirements up front (BRUF) approach where you create a detailed requirements specification early in the lifecycle.  This doesn’t work well because people aren’t good at defining what they want up front, implying that you’re estimating the wrong thing.
2. A change management process which strives to avoid “scope creep” throughout the project.  In effect you prevent change from occurring, thereby ensuring that you build something that misses many of your stakeholders true requirements.
3. A big design up front (BDUF) approach where you attempt to specify your architecture in detail before coding begins.  With BDUF you often make significant decisions without the knowledge gained from proving your ideas with working code, thereby ensuring that you’ll build the system the wrong way.
4. A software development lifecycle that is mostly serial in nature.  This reduces the control points for stakeholders, thereby hampering governance efforts and increasing overall project risk.

Ironically up-front estimates are often motivated by the desire of organizations to reduce their financial risk on IT project yet in practice this decision not only has the opposite effect it also motivates you to increase your technical risk too.  My experience is that when business people are educated on the impact of this strategy, and when they’re given other viable strategies for planning and governing IT projects, they soon choose to abandon up-front estimating.  I highly suggest getting senior IT management and senior business management to sit down and talk with each other about this critical issue.

See also:

• The XP Game
• Comparing Approaches to Budgeting and Estimating Software Development Projects
• Estimating on Agile Projects

3. People Management Tips

1. People, and they way that they interact, are the most important determinants of success on a software development project.
2. Stakeholders should be active participants on your project, not just people you interface to.  See Active Stakeholder Participation.
3. People who work together closely in co-located teams will often manage themselves.

See also:

• The EUP People Management Discipline

4. Agile Metrics Tips

The types of metrics I collect:

1. Burn rate.  How much money/time/resources are we investing in this effort?  Like it or not, someone always wants to know this number.
2. Delivered functionality.  The delivery of working software is the only true measure of progress on a software development project.  Simple ways to measure this are simply tracking
3. Velocity.  This is a measure of how much functionality can the team deliver per iteration.  This measure is often captured in the form of "use case points" or "story points" which are specific to the team.
4. Defects.  Knowing how many defects, and the severity of those defects, is an important determinant of whether you're in a position to deploy your system.

Here's a few good ideas which you should consider:

1. Keep it simple.  Start small and keep it that way.  You only need a few metrics, and even my list shown above may be too long. 
2. Metrics must add value.  The value provided by having the metric must exceed the cost of collecting it.  Remember to Maximize Stakeholder ROI.
3. Look at trends, not absolute numbers.  There are 20 defects on one project and 50 defects on another.  I can't really tell which project is in the most trouble with just this information.  The first project has had 20 defects for the last 6 months, but the second one had 200 defects two iterations ago, 110 defects last iteration, and now has it down to 50 this iteration.  Now which project is in the most trouble?
4. Combine metrics.  Consider the earlier projects.  The project with 20 defects is a $1,000,000 project.  The project with 50 defects is a $100,000 project.  Now which one is in the most trouble?
5. Don't manage by the numbers.  If you want to know what is really going on, talk with the people directly involved with the project.  In the example described above, the numbers really don't tell you what is actually going on, do they? 
6. Expect people to fake the numbers.  How do you know if the metrics I provided above are accurate?  If someone is rewarded, or punished, based on the metrics that they're collecting they are highly motivated to fudge those numbers.
7. Expect to change whatever it is that you measure.  The Hawthorne effect says that whatever is measured will improve.  There's also the side effect that it may change in ways which you didn't expect and perhaps didn't even want.  In other words, the numbers may improve but are the things they are measuring improving in a way that you desire?
8. Metrics are difficult to compare.  Your definition of a defect may be different than mine, do does it even make sense to compare the defect rates between projects?  Technology changes over time.  Does it really make sense to compare COBOL and Java projects with one another?  Processes change over time.  Does it really make sense to compare the metrics of a team following a serial lifecycle with that following an agile lifecycle?

5. Some Humor (Perhaps)

Friend don't let other friends use Microsoft Project.

6. Training

I highly suggest that all project managers consider taking a Scrum Master Workshop to learn the fundamentals of agile project management.  This article is a good start, but it's only a start.

7. Recommended Reading

This book presents a full-lifecycle, agile model driven development (AMDD) approach to software development.  It is one of the few books which covers both object-oriented and data-oriented development in a comprehensive and coherent manner.  Techniques the book covers include Agile Modeling (AM), Full Lifecycle Object-Oriented Testing (FLOOT), over 30 modeling techniques, agile database techniques, refactoring, and test driven development (TDD).  If you want to gain the skills required to build mission-critical applications in an agile manner, this is the book for you.

Are you being asked to manage a project with unclear requirements, high levels of change, and/or a team using Extreme Programming or other Agile Methods? If you are a project manager or team leader who is interested in learning the secrets of successfully controlling and delivering agile projects, then this is the book for you. From learning how agile projects are different from traditional projects, to detailed guidance on a number of agile management techniques and how to introduce them onto your own projects, we have the insider secrets from some of the industry experts – the visionaries who developed the agile methodologies in the first place. Managing Agile Projects is edited by Kevin Aguanno, a noted speaker and educator on agile project management, and includes contributions from many noted figures in the agile movement.

8. Let Us Help

We actively work with clients around the world to improve their information technology (IT) practices, typically in the role of mentor/coach, team lead, or trainer.  A full description of what we do, and how to contact us, can be found at Scott W. Ambler + Associates.