Skip to main content


Showing posts from February, 2009

The Simplest Possible Way to Get a Project Plan?

I want some work done - so make a new project...

Ok. Here are the tasks that need doing (I can enter them as a comma separated list).

My task list forecasts that these tasks are never going to complete. I guess that's because I don't have anyone to work on them. So add myself as a resource to the project.

Good. They're now being scheduled but I don't think the most important things are being done first. I need to prioritise...

That's fine. They're in order and I can create a Timebox to show what will be done in the first two weeks. Let's have a look at the forecast Gantt and Burndown charts...

Seems ok but all the tasks have the default estimate of 2 days. Next job is to estimate those tasks properly. Oh and I also need to add in the other project resources, and when they're going to be available to the project. Once that's done I'll have a plan I can show my manager.

Mmmm... That didn't take too long!

FDD sub-processes in context

Like most agile processes FDD doesn't pretend to cover every aspect of the software development life-cycle. Just the essentials for establishing a common approach. In particular FDD doesn't explicitly state how and when releases of software occur during or following an FDD iteration.

Here's a diagram that attempts to put the releases in context and also shows the distinction between the first 3 sub-processes which define the project (or iteration), and the multiple instances of the 4th and 5th sub-processes which develop the project (iteration). There can be just one release at the end of an FDD iteration or (more normally?) several releases which deploy the developed software.

What's different about Folders?

When you're deciding on the structure of project patterns for a new process, often the first thing to consider is how to represent the different hierarchies of elements that make up projects.

In FDD for example there is the hierarchy of features, normally described as being Features, which are contained in Feature Sets, which are contained in Business Areas or Major Feature Sets. This logical grouping of functionality is independent of priority and time-ordering. It may well correspond to the structure of the user manual for example or the Functional Specification should such a document be required. It doesn't give us any time view. On the other hand the hierarchy from Releases -> containing Timeboxes -> containing Features is a time-based structure. Similarly the hierarchy based on the five subprocesses of FDD also will have a time correspondence: The Definition Stage -> containing FDD#1 Develop Overall Model, FDD#2 Build Feature List, and FDD#3 Plan by Feature; The B…