Setting Up Project 2010 for Agile Development

When teams start going down the path of agile development, often one of the first things they’ll do is throw away the project plan. This is almost never a good idea as the project plan can be a guide to help with capacity planning, release planning, and managing the project resources who are assigned to tasks.  MS Project diagrams can also be an excellent communication tool if built with communication in mind.  In the spirit of Agile development, we want to eliminate all activities that do not directly contribute to the team delivering a working product.  This means working with a project plan that can contribute to sprint planning and the achievement of release cycles.

Many developers and team leads have built a strong hatred for Microsoft Project as improper setup and unfamiliarity with the tool can lead to frustration as Project tries to adjust values and balance tasks across the team.  This posting builds on my previous post on Work vs. Duration for development teams helping you to set Project 2010 up to correctly from the beginning to make working with your project plan a much better experience. 

  Project 2010 Settings


All of the following settings can be accessed within the project options.   Click on the File tab, Select Options, then select Schedule from the pane on the left.

Hour per Day — It is generally accepted that you are only going to be getting about 6.5 hours of actual development from the developers on your project as the remainder of the time will be spent in meetings, research, collaboration and other activities that, while they do contribute to the project, do not contribute to the burn down.  Because you are entering your tasks in units of work, this will allow MS Project to plan for this overhead as it levels resources across the tasks.  This takes a bunch of the confusion out of the project plan and help MS Project to give you a reasonable result should you put more than one person on a given task, building in some overhead for the collaboration. 

You might be wondering what to do in a situation where not all resources will be working like this — Project Managers, Business Analysts, System Configuration guys and the like.  If you are mixing both types of roles on one project plan, you have to get a little bit fancy, but it is not too bad.   In this case, you would need to build separate calendars for development and time-based people.  Then on the resource management screen, you get to choose which calendar you would like each person to follow.  Perhaps this would be a good topic for a future posting…

Hours per Week — This is an extension of the Hours per Day above and the two should always be adjusted in tandem to match.

New Tasks Created — This should be set to Auto Scheduled.  Project 2010 lets you designate which line items on the plan should be leveled.  In practice, you should let most things be handled by the resource leveling function and focus on the dependencies for order.  I find it is easier to just let project do this from the beginning.  This also allows you to see the task relationships right away as the linking makes it much clearer than all those lines that you have to chase like some kind of maze.

Duration is Entered in — This should almost always be set to Days.  This your barometer of how long a task will take to get accomplished with the currently-assigned resources.  For tasks that are effort-driven (development) these should be calculated units rather than something entered. 

Work is Entered in — This should always be set to Hours.  This is the units that the development estimates are recorded in. 

Default Task Type — This should be set to Fixed Work.  This means that the default task will be entered in units of Work rather than time.   This is true for most development projects.  You’ll notice that this automatically sets the check-box for “New tasks are effort driven“.

In practice, this means that you will need to think about the work that is being done and come to a conclusion as to whether it is effort-based or time-based.  With this setting, you will need to go into the properties of the time-based work items and uncheck the “Effort Based” property.  If you think you are going to have a lot of these types of work items, you might choose to add the Effort Based column to the GANTT view so you can do this quickly.

You might be asking yourself what happened to Story Points?!  What’s all this talk of hours?  Microsoft Project is a planning and sourcing tool and should be used at the point where you are planning out the actual work to be executed.  As you go into your sprint planning cycle to initiate the next sprint, there are two ways you can approach this.  From a capacity perspective, you might take the look at the historical relationship between Story Points delivered and Sprint Capacity to put this in at the Story-level.  The other option is to do this as a sprint-based work breakdown structure as you decompose your stories into individual tasks and take the summation of the individual estimates.  Both are valid approaches, but are dependent upon your discipline and the depth of your sprint planning cycle.  I prefer the latter approach, but I understand that project constraints sometimes don’t allow for that level of decomposition.


Project 2010 Settings for Agile and Scrum Projects
Project 2010 Settings for Agile and Scrum Projects

2 thoughts on “Setting Up Project 2010 for Agile Development”

  1. A reply in response to why I chose fixed work for this rather than fixed duration…

    Most projects will have two different kinds of tasks: some that are truly duration-based (server builds, procurement process, legal review, time-boxed acceptance testing) and items that are work-based (building SPROCs, coding objects, writing reports). The real litmus test is whether the task could get done faster with more people on it. This is where the 9 women can’t have a baby in one month argument comes in, but this works well for macro-level planning and by the time you have the task decomposition done to a point where that really would be painful, you should have things broken into items that a single person is doing anyway.

    In my experience, development projects tend to rely on work-based tasks, using either hours or story points as their units of work. Setting the project plan up this way allows you to see that effect if you do have multiple people on tasks, i.e. the duration will shrink to get the task done faster. If you leave the project in the duration mode, it’ll just use the resources for the full time without adjustment.

    In leveling the plan, you will still see accurate resource allocation but now you have the option to let the plan drive partial allocations against the task completion dates and even start and end dates. This lets you decouple those and use project rather than having to plan out the percentages yourself, though this might be uncommon as many work-based tasks are usually done serially rather than in parallel.

    I hope that makes sense.

  2. Thank you for your suggestions for agile development.
    I believe these are really useful tips especially for smaller groups of developers and managers where some of them are carrying more than one roles.
    In such cases, the plans are changing frequently and you have to give responses back quickly.
    I think adding columns so easily on Gantt Chart is great like you offered to manage mass updates in every task.

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )


Connecting to %s