8

We use the Scrum methodology for our software development. Since software development isn't the core activity of our company, and since this company isn't agile methods oriented yet, I need, as the ScrumMaster, to provide an interface between the Scrum methodology and the company.

The top management asks me to maintain a classic project plan, using MS Project, at mid-term (6 months), with resources defined, etc...

My question is: How can I provide a useful project plan for my top management while keeping all the flexibility and agility of my team in the daily organisation and operation, and also stay Scrum compliant?!

For me, defining resources in the project plan removes a lot of benefits of sprint concepts, right?

Improve this question

3 Answers 3

Reset to default
4

I'm a little less structured than Stephan, but have had experience with this as well.

I manage programs that combine hardware and software. The hardware is running in a strict waterfall/BDUF model, while the software is operating in "mostly" Scrum. In MS project, I have listed the overall project estimated number of sprints (obtained by doing a detailed planning sprint to get an order of magnitude estimate on the product backlog). On the MS project, I track the completion of the sprints. Originally, it was just "Sprint 1 is done, mark complete." For the MS Project purposes, I divide the total estimated backlog by the number of sprints. It allows me to present the entire project in MS Project.

I then track the software program in more traditional Scrum formats with a burn down/up and so on. If the software derails, I know about it here, and I adjust the MS Project to reflect this under the "tweak it to look right" model.

MS Project is a reporting tool and "baseball bat". It is used to report progress and also is the blunt insturment to show sales and others why we can't instantly produce a product they just thought up.

Improve this answer
1

First of all: I don't bother much about being 100% Scrum compliant, or any methodology, so the following method might arouse some comments from those who follow a methodology to the letter. I unscrupulously steal every good idea, whatever the source, as long as it fits good project management practice.

First build the WBS of your project up to work package level. Then design the plan or work package network the way you want to build the product. After estimating, this network goes into MS Project for scheduling.

The work packages represent the Product backlog. Based upon your schedule, you can devide the duration in sprints or groups of sprints with intermediate results (iterations). This depends upon the product you are building and/or the way you organise the project to track progress (increasing product maturity).

Each sprint the product backlog items are translated to a sprint backlog. From then on it is the normal Scrum proces at work here. Time is tracked against work packages and together with physical % complete and/or ETC can be fed back into MSP or any other 'system' for reporting and forecasting.

Although we're far from big design up front, as some may call it, you do need to have a pretty good idea of what done looks like. But hey, that is sound project management, right? So the work package network rarely changes (unless increasing understanding leads to an improved plan), but flexibility is allowed within the work packages, depending upon the feedback of the customer after each sprint.

Based upon your WBS and network and the size of the project, you can have more than 1 scrum team working in parallel, each team assigned to a single (big) work package or (usually) a group of work packages leading up to a specific result.

Not all the work packages have to be done by using scrum; typically only the development stuff is organised this way. If you have other work to be done as part of the whole project (like training, transition to business etc.) these may follow another 'method' of realisation. As always, it all depends ...

Hope this is usefull.

Improve this answer
0

Not sure if you've seen it, but the Project team has released a free Scrum Solution starter for Project 2010 that will allow you to manage your product backlog, sprint backlog, and generate sprint burn down charts directly from within Project.

http://archive.msdn.microsoft.com/P2010Scrum

Improve this answer

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.