Now that you have the basics about what agile development entails, let’s look at how to build an agile project using the Microsoft Project suite (Project Professional, Project Server and Project Online).
The key to success is to remember that Project is a relational database. Thus, it’s neither a waterfall tool nor an agile tool. It’s a database that you can configure to be either or both. If you look under the hood of other agile tracking and planning tools, you’ll find that every one of them is a database or contains a table structure.
So considering Project as a database, you can apply this mindset and approach the building of database elements into your schedule in a way that helps you to manage in an agile view and switch back to waterfall, including the elements necessary for filtering, grouping, sorting and reporting.
Building Agile Views, Tables, Custom Fields, Filters and Groups
Let’s review the steps to help you have a good agile Project schedule and leverage the working elements of this.
TIP! If you like watching videos, I encourage you to subscribe to my company’s YouTube channel for topics like this one. Click here to watch a demonstration on how to build and leverage an agile schedule.
Building Agile Custom Fields
Tracking meaningful parts of your schedule is a basic element of an agile project. You have to create the layout for those elements that you want to track — that is, custom fields that address the story point, priority, iteration, sprint and the like.
This screenshot is an example of an agile Project Template that we use all the time.
Most scrum or agile schedules have pivotal fields to help the teams track, manage and report work. Here are some examples, but feel free to add you own as necessary for your particular operation.
- State: Open, closed, in-progress, done, not done;
- Sprint: What sprint a task is tagged with regardless of where you organized the activity or summary task;
- Customer need: Another way to set your priorities or rank activities in order of importance;
- Story points: A common mechanism for estimating the size of the overall work being requested and then measuring whether you have too much complexity for a sprint
To read more about creating an agile schedule with Project 2010, check out this MPUG article by Vincent McGevna.
To create these fields and other custom fields, follow this process:
- Go to the Project Tab in the Ribbon.
- Click on the icon for Custom Fields (as shown in the screenshot below).
- Click on Task choice in the top.
- Highlight the Text1 field.
- Click on the Rename button.
- Rename Text1 to State.
Custom Field State
To fill in the possible values for the State field, follow these steps:
- Highlight the State field.
- Click on the Lookup button.
- Fill in the values wanted in the Lookup table.
To mark a particular choice as the Default value, you follow this sequence:
- Check the box for Use a value from the table as a default entry for the field, as shown in the “Edit Lookup Table for State” dialog.
- Highlight the choice you want to make the default.
- Click on the Set Default button for any value you want to auto-populate when a task is added to the schedule.
Custom Field Sprint
To set up custom fields for Sprint, follow the same process as you used for agile. Here are the lookup table values.
I typically add enough sprints to map out 1.5 times the length of the project. If each sprint is two weeks and the project lasts four months, that total might be 13 sprints. How did I arrive at that number? Divide 4.33 weeks per month by 2 to get the number of sprints, then add 50 percent of that number to get the total sprints:
4 months x 4.33 weeks = 17.3 weeks
17.3 weeks / 2 weeks per sprint = 8.66 sprints
8.66 sprints x 1.5 = 12.99 (rounded to 13)
Custom Field Customer Need
For the Customer Need field, remember that you want to establish priority for your sprints. Usually, there’s no better way than to align it with the level of importance placed on it by the customer, if possible.
Follow the same process as we did for other fields in creating the field and renaming it. Here’s the lookup table:
Custom Field Story Points
The Story Points feature lets your development or technical teams size complexity vs. trying estimating hours. It doesn’t mean you don’t try to figure out hours. It recognizes the inefficiency of doing the full estimation process for tasks that may never be worked on because you may cut or remove scope in early planning.
Also remember, in agile you find out that complexities may change as you go along, so trying to estimate hours early or up front may not be a valuable use of anybody’s time.
This custom field is a Number field. To create this field:
- Change the Type dropdown at the top to Number.
- Rename Number1 to Story Points and you’re done.
Adding Deadlines to Milestones
We often want to hard-code a date in a schedule because we have been given a specific date for a given task to finish. However, as soon as a date is typed into the schedule, the schedule becomes constrained or stuck in time, and it is no longer dynamic.
This may sound like what you are looking for — keeping your activities from moving beyond a sprint window. However, I find that having a deadline allows the technical teams to report progress, and you can have Project alert you if the remaining work will slip beyond the overall sprint time period.
To avoid this scenario of hard-coded dates and prompts about constraints, you can set a deadline for a task. To do so, you set a date on which you expect a task to be complete. If the finish date of the task goes later than the deadline you set, an indicator flag appears. This indicator communicates to the project manager that something needs to be done in order to bring the schedule in line.
In this example, Sprint 2 is expected to complete by 6/5/12.
Instead of hard-coding the finish date by typing in the date, we create a deadline of 6/5/12 for the task, Sprint 2 Complete. To do so, you follow this sequence:
- Double-click on the specific task to bring up the Task Information dialog for that task.
- Select the desired date for the deadline, as shown.
If the Finish date for the Sprint 2 Complete task becomes greater than the deadline “6/5/12,” the deadline Indicator will display this dialog to let us know that we have an issue with this task.
Creating Agile Groups or Groupings
Groups are also useful objects for displaying data in a more effective way. To create such a group, we specify a group, and then the system displays the tasks based on that group.
I also like the roll-up groups provided for any number, cost or work field, and they give you the ability to collapse or expand the information easily.
To create a custom group, follow these steps:
- Click on the View tab in the Ribbon.
- Click on the Group by drop-down menu.
- Click on “More Groups” to display the More Groups dialog.
- Click on “New” and then define your custom group
Creating a Custom Group for _Burndown
I use the underscore in a field name to bring custom objects to the top when I do a sort, but commonly people like to number them (1.Burndown, 2.Completed, etc.)
The following screen shows how to create the custom group _Burndown with the group definition dialog.
Custom Group _Sprint
The key to a group is defining its look and feel and the layers that you need to group. Don’t include too many levels because the project schedule will look too busy and be hard to summarize.
The following screen capture shows the definition of the custom group _Sprint.
Creating Custom Agile Filters
Especially when an agile schedule is embedded in an overall waterfall project, you’ll want to create filters to find and manage your views quickly.
Filters also help you to focus your data display. A filter selects the Task Rows to display based on the filter’s definition.
To create a new custom agile filter, follow these steps in the dialogs shown below:
- Click on the View tab in the Ribbon.
- Click on the Filter drop-down menu.
- Click on More Filters… to display the More Filters dialog.
Click on “New” to define your new filter.
Custom Filter _Burndown or _Sprint
To build a filter, you simply need to be sure that you know what you want to exclude or include.
In the following dialog box, I make sure to add any value that I want excluded and give it empty or null values, as in the case of filter _Sprint to filter out any tasks that have no value selected.
Backlog Tasks
An agile team will constantly be adding, removing, or reprioritizing in this area.
For the backlog tasks, we want to make a configuration change. Instead of setting these tasks to the default constraint type, “As Soon as Possible,” we change it to “As Late as Possible.”
By doing so, you can have the work always scheduled in the future, and then you move it into the sprint that you want to do the work in.
Follow this sequence in the dialog shown to make this change to all the backlog tasks at the same time:
- Highlight all the Backlog Tasks.
- Click on the Task Information icon in the Ribbon.
- In the Task Information dialog, you can then change the constraint type to “As Late as Possible.”
Remember, Project is a Database
I hope this was helpful for you. I have found that viewing Microsoft Project as a relational database really frees up the minds of those who are using it and allows the tool to be used with agile, waterfall or any mix of these methodologies and disciplines.
The underlying goal is to keep the work moving forward while still providing roll-up reporting on agile teams and their progress.
If you would like a copy of any template referenced in this article, please reach out to me directly at Tim.Runcie@Advisicon.com. I like to increase productivity with working examples.
Related Content
Webinars (watch for free now!):
Key Agile Concepts Illustrated
Using Agile Best Practices with Project PPM Technologies
Agile PPM – When Your Teams are Agile, but Power Skills Thinks Waterfall
Articles:
What is Agile Project Management?
5 Metrics for Agile Development
The Basic Roles in Agile Projects
Leveraging Agile in Microsoft Tools
Agile Disciplines
