Content
You are here:
Are there best practices for managing a project with openproject
Added by AJ SA over 10 years ago
Hi,
First thank you for all your work.
Second, I am just looking for best practices for managing a project using openproject, I mean:
- Naming workpackages
- Organizing them in backlog and them moving to sprints
- Organizing subprojects….
We were working with redmine for years, but your agile aproach is worth a rethink
Replies (1)
Hi Antonio,
using OpenProject, you can continue your redmine workflow as before (the backlogs plugin is just an extesion) if you want to.
The backlogs plugin (which we use here on openproject.org) is based on the scrum workflow although we are constantly adapting our workflow to our needs.
Naming workpackages
We try to give our WorkPackages informative names, but there is no guideline (I am aware of). Sometimes we add “tags” in brackets to subjects so that we can better filter for WorkPackages that belong together. A good example is this WorkPackage:
Here you see the
[API]
“tag” and how we often structure user stories. (We want to have real tag support in the future)Organizing them in backlog and them moving to sprints
Currently we have a 3-week sprint cycle (there can be exceptions) with a sprint backlog for every sprint. Bugs which come up during the sprint are thrown right back into the sprint backlog, if they are caused by our sprint work. Otherwise they are collected in a global backlog and prepared for the next sprint.
(As always) There is often more work to do than we are capable of finishin. This leads to a growing backlog. Thus we clean the backlog from time to time (removing obsolete bugs or feature requests, priorizing things etc.).
From that backlog we consider the WorkPackages with the highest priority to be included in our next sprint. For each WorkPacakge we estimate how long we probably need to implement and test the feature and try to solve all problems that hinder implementing it.
Organizing subprojects….
We have one main project (“openproject”) and one sub project for every plugin. There are also several projects for organizational things (like the OpenProject Foundation planning). In general every independent set of ideas might get it’s own project, especially when they need different access rights (because there are different stakeholders involved, from a different company maybe). But we strive to keep our list of projects clean and organized (there is no shame in letting a project die, if it is done or abandoned).
I hope that helps a little,
tessi