I see these main areas where Project Server 2010 would be of benefit:
Timesheets can automatically update Project Plans with Actual Work and Work Remaining on assigned Tasks;
The ability to define common, standardized custom fields for Tasks;
The custom reporting capabilities of the Business Intelligence center.
If you’re already using Timesheets, you can piggyback on the significant effort you put into getting there. If you don’t, you can manually update Actual Work directly in your Project Plans.
Based on my limited experience with Scrum, I’d expect to do some configuration work on the Project Server side, and learn some new habits on the Project Professional side.
Project Server Configuration
Define custom Task fields for:
Scrum Task flag (yes/no);
Deliverable (one line of text) ;
Sprint (a number).
Develop Excel pivot tables in the BI center for
Backlog reports
Burn-down reports
Modify the Timesheet view to include the Deliverable and Sprint fields (read-only). Project Professional
Define the Scrum summary task named Scrum” inside the Execution phase;
Define two summary tasks inside the Scrum summary task, one named “Sprints” and one named “Backlog”;
Set the Backlog’s predecessor to be the Sprints summary task.
For each Backlog deliverable, create a single Task and define its custom Tasks fields as follows
Set “Scrum Task” to Yes;
Set “Deliverable” to a unique value;
Set “Sprint” to zero (indicating it’s in the Backlog).
To define a Sprint:
Create a summary task under Sprints, naming it “Sprint n” where “n” is a number;
Move Deliverable Tasks from the Sprint from “Backlog” into “Sprint n”, setting each one’s custom Task field named Sprint to “n”;
As you complete each Sprint, all its Deliverable Tasks must be completed. If one of them has not been completed, you must:
Create a new Backlog Deliverable Task for the Remaining Work, using the same Deliverable value in that custom Task field;
On the earlier Deliverable Task in the completed Sprint, Set the Remaining Work to zero, which will mark it complete.
Reporting
You can develop reports specific to managing a Scrum by selecting only those project tasks that have the Scrum Task flag set to “Yes”.
You will need to develop burn-down reporting that will show:
Percent of total Sprint Task Work scheduled and work completed, by Sprint.
Calculated burn rate, per Sprint and running average.
After each Sprint, refer to the burn rate reports and modify the resource allocations in the remaining Backlog tasks, to refine the predicted completion date for the Scrum.
================================
This is the approach I’d take, but I’m hoping there are folks out there who are currently using Project Professional (and maybe Project Sever) to manage a Scrum effort.
Let’s see if we can correct / refine / expand the above.
================================
A note about moving Tasks in a Project Plan.
In Project Server 2010, when a Timesheet is created, it links each timesheet line to a Project Plan Task using the Task’s UID. If you move that Task’s location in the Project Plan by dragging it, you’ll be OK. If you “move” that Task using Cut and Paste, you’ll delete the old Task and create a new Task, with a new UID, breaking the link to the Timesheet!
As long as no Actual Work has been done, that’s not an issue; once Actual Work has been logged, you can be in trouble. To be safe, avoid using Cut and Paste with Tasks in Project Professional.
