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