Can Microsoft® Project Be Used for Agile Projects?
By Keith Wilson, B.Comm., PMP, MCT, MCTS | Senior Trainer and Consultant, IIL “
Can Microsoft Project be used for Agile projects? Yes! Customizable fields and custom groups can be used effectively to create an Agile template. Custom fields allow you to add project-specific information, which can be used to filter or group tasks to provide different views into the Agile schedule. It is possible to create a schedule for planning, communicating, and tracking Agile projects, or with an Agile or a hybrid method.
Key characteristics of the Agile development method are Iterative, Incremental, Embraces change and Delivers a deployable product early for a quick ROI.
Agile teams deliver complete and functioning code within short iterations. During the iterations, all of the necessary work to take features from an idea to a working product is completed without artificial dependencies that prevent work from being done in parallel. The end result is that portions of the product are delivered on a regular and frequent basis. This gives stakeholders a much better idea of the state of the project because they can see and use the end result as it becomes available.
The strengths of Agile development:
- Delivers minimum usable subset
- Delivers on time and to cost
- Iterative development for evolving solution
- Flexible processes
- Collaboration of the whole team
So what project-specific data must be added to create an Agile schedule?
An Agile project starts with a backlog, which is a list of features to be implemented, and a number of iterations or sprints to implement those features, which are represented as tasks in the schedule.
In addition, each feature will have a priority and a size estimate represented in story points and will be mapped to a sprint. Story points (which can be numbers – e.g., 1, 2, 5, 8) are relative values based on the size or difficulty of a user story relative to other stories. When you estimate using story points, you estimate the “bigness” of a user story compared to other stories. Each feature and sprint will also require a status (e.g., not started, in progress, or done).
To create an Agile project schedule we need to know:
The duration of each sprint, the release date if there is a planned release including several sprints, the priority of each feature in the backlog, the feature complexity or story point value, user-need or priority and state. In addition, we will need to know the resources and the percentage of their time available per sprint and each resource loaded labor rate.
We will need to create custom fields for Agile-specific information including:
User Need Text Field
Lookup Table: Low, Medium, or High
State Text Field
Lookup Table: Not Started, In Progress, or Done
Story Points Number Field (Estimate of Story Points)
Set Calculation for task and group summary rows to Rollup: Sum
Sprint Text Field:
Lookup Table: Backlog and Sprint 1 through Sprint n
It will also be necessary to create two Groups:
Sprint Group by Sprint.
The Sprint group will list all features in each Sprint; story point totals rollup for each sprint. Features not assigned to a sprint will be grouped under Backlog.
Burndown Group by State, then by Sprint.
The Burndown group will provide story point summary by categories: Done, In Progress, and Not Started.
Story point totals roll up.
The Agile schedule will also require two summary tasks: Sprints and Features. Under Sprints, enter the expected number of sprints, including the name and duration of the sprint, and link them in sequential or finish to start order. Then list the features under Features summary task. Make each of the features a milestone, by indicating a zero duration. By default, the features will all be in Backlog. To assign a feature to a specific sprint, select the sprint number in the Sprint drop-down. Also, when you assign a feature to a sprint, set a finish-to-start predecessor to that sprint so the expected finish date of each feature will be known. When tracking the project, if one or more features are not completed in a specific sprint, it is easy to just update the sprint number and the predecessor to move those features to another sprint.
Build a resource pool with real or generic resources. Be sure to include a rate per resource and other know attributes such as Calendar, Max Units, Group, and Rate. Once you have the resource sheet complete, assign the resources to each sprint and indicate the percentage of time that they will be working on the Sprint. Since there is a rate per resource, Microsoft Project will multiply the duration by the percentage allocation time for each resource and then by the resource rate. It will then summarize each resource cost per sprint to provide a total cost per sprint, which in turn can be rolled up to show the total cost of the project.
The following is an example of a schedule with sprints that have a duration of 15 and a dozen features and is using the custom Burndown group, grouped by state and sprint. It also displays the total number of story points for each of these states:
Custom fields are a powerful feature of Microsoft Project, and when used with custom groups, we can actually use Microsoft Project for an Agile project without knowing which features each sprint will be addressing. Given the duration of each sprint, the resources, resource rate, and percentage assigned it will be possible to calculate the cost per sprint; and if the sprints are rolled into one release, the total cost, and duration for that release or project.
About the Author
Keith Wilson is a Microsoft Project and Project Management Senior Consultant/Trainer for International Institute for Learning, Inc. His background includes over 25 years of successful management and consulting experience, with a focus that includes project management, training, and business planning. Well known for his public speaking skills and enthusiasm, he has been a welcomed facilitator at numerous Fortune 500 corporations, Universities and Associations worldwide.