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