Author: Vincent McGevna
Vinent McGevna, PMP has over 25 years of engineering project and program management experience, and has been using Microsoft Project for almost 20 years. During this time, as Project evolved, he learned to turn it into a powerful and versatile planning tool. He recently published a book: Schedule Centered Planning: An Incremental Approach for Plan Driven Projects. An appendix shows how he has used fields, filters, groups and views to create a schedule that is a plan, and then manage the project using that schedule. Contact him at Vincent@pmsuccess.com or check out his website.
Creating an Agile Schedule with MS Project
Use Fields and Groups to Create an Agile Schedule with MS Project I have read many comments that MS Project cannot be used for Agile projects. While I agree that Project is not the best tool for Agile, I disagree with those who say that it cannot be used at all. Customizable fields and groups are a powerful feature of Project that allow it to be used effectively for a wide range of projects. Here we will show how to use some of those features to create a schedule for tracking Agile projects. An organization with a broad range of projects that needs MS Project for the large complex projects can also use it for those projects that might be more effectively developed with an Agile or a hybrid strategy. Custom fields allow you to add project-specific information. This information can be used to filter or group tasks to focus in on specific data or just to provide different perspectives on the vast amount of data that Project maintains. I use text fields most often and use the lookup-table feature to assure uniformity. What Goes Into an Agile Schedule? 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. These are the tasks in the schedule. In addition, each feature will have a priority and a size estimate in story points and will be mapped to an iteration, or sprint. Each feature and sprint will also require a status-e.g., not started, in progress, or done. This Agile-specific information is maintained in custom fields. Unfortunately, Priority is already a field in Project, so we will have to choose another name, and User Need is a good descriptive alternative. Similarly, Status is a field in Project, so this will be changed to State. Thus we have four custom fields to implement: User Need          Text Field Lookup Table: Low, Medium, or High 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 State               Text Field: Lookup Table: Not Started, In Progress, or Done User Need, Sprint, and State use lookup tables. In addition, since features start out in the backlog before they are mapped to a sprint, the lookup table for Sprint will set Backlog as the default. Story Points is a numerical field. Since it is important to track totals, the summary task for this field will be set to Rollup: Sum. To learn more about creating agile schedules in more recent versions of Microsoft Project, read this article by Tim Runcie. Setting up the Custom Fields . . . Below are some screen shots for setting up these custom fields. The custom fields dialog shows the three text fields. Sprint (Text3) is highlighted and you can see under Custom attributes that Lookup. . . is selected. Also note that below Custom attributes is Calculation for task and group summary rows. While the Text fields allow only None, the Number fields allow a Rollup, and in that dropdown menu there are many choices such as Sum, Max, Min, Average, etc. In the number field for Story Points, I chose Sum, and we will see how this is useful when we set up groups. Below is the lookup table for Sprint, and you can see that Backlog is highlighted and there is a check in the box to Use a value from the table as the default entry for the field. Whenever a new feature or sprint is added to the schedule, it will be in Backlog. The sprint task should be changed right away to the appropriate number and a feature should be changed from Backlog to the appropriate sprint number when it is mapped to a sprint. . . . and the Groups With the fields defined, two Groups are needed to give the required displays: Sprint          Group by Sprint. Lists all features in each Sprint; story point totals roll up for each sprint. Features not assigned to a sprint will be grouped under Backlog. This grouping can be used along with auto-filtering to select the highest need first. Burndown     Group by State, then by Sprint. Provides story point summary by categories Done, In Progress, and Not Started. Story point totals roll up. Below is the Group Definition dialog for Burndown. You can see that it is grouped first by State and then by Sprint, two of the custom fields. Also note that the name is preceded by an underscore and that Show in menu is checked. I do this for my custom groups because the underscore puts them at the top of the list and they will all be together at the top of the Group dropdown menu. Add the Specific Sprints and Features The Agile schedule requires 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 order so that when one is done the next begins. Then list the features under Features. Make each of these a milestone. The features will all be in Backlog. To assign a feature to a specific sprint, select the sprint number in the Sprint dropdown. Also, when you assign a feature to a sprint, set a finish-to-finish predecessor to that sprint so the expected finish date of each feature is known. Following is an example of a schedule with four sprints and a dozen features. Each sprint has three weeks (15 days) and all of the custom fields are visible and have been filled in. Now, applying the Sprint group, the information is sorted according to sprint and you can see the start and finish of each sprint as well as the total number of story points assigned to each sprint. Applying the Burndown group, you can clearly see what is done, what is in progress and what is not started. You can also see the total number of story points for each of these states. Sprints 1 and 2 are done, with a total of 45 story points. When tracking the project, if one or more features is 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. Also, if you just want to see summary data, it is easy to close up the Sprint group. Summary Custom fields are a powerful feature of Microsoft Project, and when used with custom groups, filters, and views, they allow you to create schedules that are more than just schedules, to focus on what you think is most important at the current moment, and to change your focus easily and rapidly. This makes creating, tracking, and managing your schedules a lot easier. Related Content Webinars (watch for free now!): Key Agile Concepts Illustrated Using Agile Best Practices with Project PPM Technologies Articles: What is Agile Project Management? 5 Metrics for Agile Development The Basic Roles in Agile Projects Leveraging Agile in Microsoft Tools Agile Disciplines
Is Microsoft Project a Project Management Tool?
In an October 2009 article, “Best Practices for Microsoft Project, Part 1,” author Jim Park makes the statement: “Microsoft Project isn’t a project management tool. Let me repeat that last sentence: Microsoft Project is not a project management tool. It was developed as a schedule tracking application, but has become accepted over the years as a comprehensive project management tool. It is not the most effective tool when it comes to brainstorming activities like project planning…” MPUG member Vincent McGevna, PMP, took exception to Park’s statements: “I have been using Project since it was first released, and I can assure you that it is not only a project management tool, but it is the project management tool. Clearly, it is not a standalone tool, but given the complexities of project management, there cannot be a standalone tool. That’s why we have an Office suite…” MPUG asked McGevna to offer his counterpoint to Park’s assertion. This article is that counterpoint. Microsoft Project as a Project Management Tool The project manager is responsible for creating a project plan, tracking progress against that plan, and updating the plan when necessary. According to PMI’s PMBOK, there are eight areas that might be addressed in a project plan. Of these, the schedule is the single most important. It’s built on the work breakdown structure (WBS), identifies the resources needed, and will have tasks to carry out the quality plan. Risks are best identified during schedule creation, and all efforts to mitigate risk as well as contingency buffers must be added to the schedule. The schedule then identifies the timeframe for each risk. Procurement must be included in the schedule, especially lead times and pre-procurement activities. Costs are reflected by the assigned resources, by procurement and by activities such as travel, and thus closely tied to the schedule. The communication plan is the only area not reflected in the schedule. However, the key dates and their status are among the most important pieces of information to be communicated. Thus, the scheduling tool is the most important tool in the project manager’s toolbox. It must be robust and configurable to deal with the broad range of project types, sizes, and complexity. As an engineering project manager, I have found that Microsoft Project fills this need nicely. Having used Project since its initial release, I have created and managed schedules with hundreds, even thousands of tasks. Microsoft Project : Project Management Features Many of the features of Project that seem complex are, in fact, well thought out, and give the project manager the power to manage any schedule. By using custom fields, groups, and filters, I can slice and dice the schedule to focus on a specific aspect, such as an individual resource, one or more deliverables, or an integration phase. Flags and custom fields are useful to identify risk and quality related tasks, and with filters or AutoFilter, it’s easy to check on their status or create custom reports to share the information with stakeholders. Resource views along with network diagrams are great for resource leveling. Dealing with schedules of 500 to 2,000 tasks and with 20-plus resources, I have never needed to level with Project’s leveling feature. However, I have found the leveling feature useful to split tasks when team members have to work on short, high priority tasks such as document reviews. Using Microsoft Project as a Project Management Tool By using the capabilities provided by Project, I’m able to build most of my project plan into my schedule. When done scheduling, I have a very good understanding of the project I’m managing. Then the real fun starts — managing the project. For this Project provides additional, customizable views and tables, along with earned value calculations. This makes tracking the project straightforward. Then, the same features I use for planning are invaluable for the inevitable replanning. I also rely on two add on tools, both from Critical Tools. WBS Chart Pro is an essential Project utility I use to create the WBS as a tree diagram. (Some people use mind mapping software for this.) The tree diagram is more useful to share and review than an indented list. PERT Chart Expert produces network diagrams. While these can be created within Project, I prefer the format in PERT Chart Expert. Every project manager should have a tool like Project in his or her toolbox and should know how to use it effectively. Too many project managers fail to take advantage of the power it provides.