In a stream of Random Thoughts ..

Musings and rummaging …

Emacs and Org-Mode for Project Break Downs and Estimation

At work I am asked now and then to provide an estimate for, how much time it will take to develop a certain feature, or functionality for clients/customers. I am sure, most people workingare asked do similar tasks. It is not my favourite thing to do, but luckily emacs and org-mode makes it less of a bother. Inspired by Daryl Mannings blog post on his productivity system, I thought, I would share mine for projects.

Using emacs and org-mode pretty heavily to keep track of tasks and obligations for work, it made sense to use org-mode for this type of task as well. Previously, I have kept everything in One Big Org file, but it became quite unwieldy over time.

Lately, I have found my self using a set structure, which I am pretty happy about. The structure is build around:

  • Directory structure

  • Fixed structure of an org-mode file

The Directory Structure

projects
├── completed
├── inception
└── onhold

I keep the entire directory as a git repository, with a cron job to auto commit changes, if any.

For each "project", that I am working on, I create a file, in one of the following directories, using these guidelines:

Directory Rule
projects (top level) Holds active projects, that I am working on, or tracking
completed Holds completed projects (until deleted)
inception Starting place for new projects, that might become an active project
onhold Sometimes projects get stuck, or put on hold.

I keep the files in the project and inception in my agenda view, as I also use the items in there to plan my work for the close future.

Initially projects are placed in the inception folder. If they fizzle out, I just delete the file. It is in git, so I can find it, if I really need it. If the client/customer accepts and orders it, I move the file to the root folder, so that the files there represents on-going projects.

If the project stops temporarily (for any reason), I move it to the onhold folder. Finally, when it is delivered I move it to the completed folder. I keep it there a while for reference in case there is dialogue with the customer. Eventually I clean up and delete old projects from the completed folder.

Structure of a project file

I have started using this structure, which is actually populated with a yasnippet template, to make it easy to setup.

The file structure looks like this:

I do the project break-down and later on tracking of timespend under the WBS section, where as I use the Reporting Heading for easy access to reporting data.

Using orgmode for Project Estimation and Planning

When starting a project, I use the children under the WBS section as follows:

Section Purpose
Initial Requirement Validation In case customer, is structured enough to send a list of requirements
this is where I list them, and then I compare the solution against
those requirements
Design For larger projects with some complexity, I use this section to write
out the designed solution, that I can then communicate to the
client/customer and validate against stated requirements
Sometimes I will write down multiple design suggestions, so that they
can be compared.
Implementation Here I break down the project into smaller features/tasks, thats must be
accomplished in order to implement the project
Deployment Keeping track of where the current solution is deployed in order to
track status

If the project must be estimated I use the project break down as a place to actually add estimates onto all activities, so that org-mode can then sum-up and fill in the details. If the project is a larger one, I occassionally also but estimates on design work.

For planning purposes, I usually schedule time in my calendar to work on active projects. The scheduled tasks are then automatically added to my agenda view, which I visit every morning.

Utilizing the columnview dblock, I can both easily see the total estimated time, but also when I plan to work on the items. Deadlines can also easily by added like so:

Conclusion

In conclusion I find the above structure provides me the following benefits:

  • traceability through:

    • tickets number

    • Links to ticketing system, or links to email etc

  • Flexible, since its easy to add in new sub sections as need

  • Provides overview by utilizing standard org mode features, such as scheduling, estimates and clock sums.

  • Ease of reporting due to the inherent handling of clock data on items.

I hope, somebody found it interesting. If you did, or have suggestions or feedback, you are welcome to reach out at comments @ randomthoughts.dk