Project Closures in Scrum

scrum

In a typical software development environment, project closures mark the end of a project.

  1. Project records are completed and archived,
  2. resources released,
  3. issues and lessons are documented, and
  4. a formal dinner/party held for celebration.

Last step is optional, though is very motivating for participants. 🙂

Contrast this with Scrum. I know that scrum runs on stories from backlogs. So, technically, every iteration closes certain stories. So, there are two questions here.

  1. For a group that works on multiple simultaneous projects, how do project closures fit in?
  2. For a project that involves multiple groups, how does this concept apply?

Or, does project closure term not apply to T&M projects at all?

Best Answer

For a group that works on multiple simultaneous projects, how do project closures fit in?

First, "multiple simultaneous projects" is considered a really bad idea. The point of scrum is to sprint and be done. Switching projects to start another sprint is disruptive. Doing two projects at one time isn't a sprint. It's a mess.

However, Scrum is no different from a non-agile (waterfall) method. When the backlog is reduced to approximately zero, you're still done. Just as done as if you had a waterfall approach instead of an agile approach.

Sometimes the backlog is non-zero, but the customer is delighted and doesn't want any more. So you're just as done. Usually done earlier and cheaper than a waterfall (which has to build everything, even the ideas that turned out to be useless.)

For a project that involves multiple groups, how does this concept apply?

Same as a non-scrum project with multiple groups. Nothing changes about the people. They still like a good party.

Or, does project closure term not apply to T&M projects at all?

Why would the billing change anything about the nature of the work or the ceremony at the end?

Related Topic