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
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.
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:
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:
|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
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
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:
|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|
|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|
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.
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:
In conclusion I find the above structure provides me the following benefits:
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