Even though Scrum asks for “only as much documentation as required,” for most project managers, this equals a high level project plan showing dependencies and resources. Afterall, a sprint back-log doesn’t quite cut it when one is trying to work out whether that July 1st deadline is widely optimistic or not.

When planning a Scrum project it is essential to get the whole team to define what the key deliverables will be, for instance, will there be a clickable prototype in sprint 2 or only wireframes? Will the output of Sprint 5 go live or will we just release to Beta?

Once these questions have been asked, the project manager can construct a project plan in the old fashioned way but bearing in mind the fact that they don’t need to have absolute estimates as the wonder of scrum is that we make the work fit the timescale. However, we must ensure that the bear minimum requirement IS possible within the time and budget provided otherwise the team is still at the mercy of old fashioned values inherent in the SSADM approach.

Once the timescale has been agreed by everyone involved, the project plan doesn’t need to be updated, because the scrums are already set in stone and the broad deliverables outlined. The magic of Scrum means that the planning task is now the job of the sprint backlog and burndown chart but thanks to good old fashioned MS Project (or whatever takes your fancy) we don’t have that nagging feeling half-way through the project that we might be delivering a half-baked solution.