Redmine

What functionality is different between versions and milestones? How does Trac differentiate them?

For example, you have SomeApp in version 1.0 and 1.1 and now you are working on 2.0.
It's bigger púroject, so you have to divide development into phases - milestones. You need to have deadline for each milestone, and you need to track how much work is done in each milestone, so you can track both nr of issues open/solved per milestone and time estimated/done/remining.

Versions are reserved relly for SW versions. Also, versions are in tickets when reporting bugs, because you need to track in which version was bug found, in which version you would like to fix it and actually, in which version it was fixed.

I see what you are saying. However, i don't see how you couldn't just use "versions" for this as well. Or sub-projects, one for each milestone. Could you not create a version for each milestone? 1.0.1, 1.0.2 ... and so on? You could still assign tickets (issues) for each thing that needs to be done (script or document written) to a version, which can be given a date, and think of it as a milestone. I'm not arguing for not having milestones, i'm just trying to see if there is a way to get most of what you want using the current tool.

Hope you don't mind my jumping in here but I also tend to favour the name change from Version to Milestone.

I understand both sides of the argument but I think something as simple as changing the word from Version to Milestone would help a lot.
Milestones are more generic and opens up Redmine to a new set of users who are not involved with managing software projects. I personally use it to manage software and non-software projects and feel the term Version is a misnomer when applied to non-software projects.

Along the same lines, but slightly off topic, is the concept of iterations. In agile software development, iterations are used frequently and I do not see how to apply this concept in Redmine. Therefore, I think it would be very useful to add support for Iterations in Redmine. In my view, it would take several iterations to complete a Milestone. To simplify these combined changes, one could treat Milestones as a container for Versions (where Versions could then become synonymous with iterations).

I've not added this as an official request because I'd like to see what others think of this idea first and maybe have it fleshed out here through discussions first.

First of all, i'm all for changing "versions" to "milestones". That seems like an easy win.

That said, i still don't understand why one can't create a series of smaller milestones? Why do you need a hierarchical grouping of milestones? If i were doing Scrumm or Agile dev, once you've come up with the changes for the current "iteration", create a new milestone, and assign tickets with the needed changes to that milestone. Why do you need "smaller" units of work? The real question is, to quote Ronald:

"In agile software development, iterations are used frequently and I do not see how to apply this concept in Redmine."

What don't milestones get you that this "new" idea of iterations would? You don't really spell it out, what the functionality of "iterations" would be in redmine.

Here is an example of using Milestones/Versions to do what i hear you want to do (keeping in mind that i don't really have any idea what it is you want to do ;)

You want to get to milestone 1.0. You create point milestones for each iteration towards 1.0 - 0.1, 0.2 ... 0.2345. Or to use more English sounding milestones:

"Finished Project" - 1.0

Iterations to reach "Finished Project" - "Iteration Week 1", "Iteraction Week 2"...

I'm interested to hear more about this whole subject - keep up the discussion!

Will it be sufficient to have a dropdown box (when adding/editing a version) to define if this object will be called "Version", "Milestone" or "Iteration"?

And what about simillar solution like in Trac: there can be both Version and Milestone, but there are visible only when there are some milestones/versions defined, so for projects where are no milestones defined the look of issue will be same. Anyway, I think that it's better to have support for both versions and milestones at the same time rather that select for name. It's because we can have project with tho majour versions (1.0 and 2.0) but we need to plan some milestones to somplete project.

In my point of view, versions are really tighly bond to SW versions, so it's usefull for reporting in which version exactly was bug found or in which version we wopuld like to fix it. Milestones act just for organizational purposes, so it's not actually bond to exact version. One of milestone can be "Finish complete translation", but this milestone can be postponed etc, while mail development continues.

Maxim - what's keeping you from using Versions as a general organizational tool now? Yes, they can be tightly associated with a release/code, but they don't have to be. You can use them as a simple "all these things are related to this" tool.

It really just seems to be a difference in terms/language, rather then a difference in function. I've yet to read anyone detail what the functional difference, in redmine, would be between versions and milestones.

Sooo, any more discussion on this? Anyone? ;)

Errrg, I'm just using versions for mile-stoning now ;)
I still think that milestone is more descriptive term, but there are probably more important issues to solve now...
Again, thanx to all for great app!

Maybe it has to be configurable setting :)
If the functionality is the same, it's just a label.

You perfectly get my point: it's just a damn label :)

I recently went through the process of converting Version to Milestone, but found that the version label is also being used for document revisions. "Milestone" in that context doesn't make sense. When I upgrade to 0.7 I'll see about splitting this into different labels, and perhaps submitting a patch.

i would like to see both.

Example:

version 2.0 (3 Milestones), Version 2.5 (1 Milestone)

For finishing Version 2.0 there are a few milestones to finish before

Milestone1: planning
Milestone2. programming
Milestone3. beta testing

So if Milestone 1 is not reached its not possible to start/finish milestone2.

If Milestone2 needs to pushed back all following milestones and Versions are pushed back as well.

So you could see all open tasks for Version 2 (all Milestones) to finish or just the tasks for Version2/Milestone 2 to finish.

Tom,

No offense, but your example is a non-sens: every project is a heavy iterative process. So if you can't do anything in M2 if M1 is not ended, that means that you forbid to work again on M1 once you start M2. Hard blocking work on a milestone because an other set of milestones don't make sens: the better approach is to explain how you want user your tracker to your team rather to take technical restriction.

Tom,

Yes youre right, my explanation was weak ;)

Ok, ill try to make it more understandable:

1. See the Gantt-Project ... these relations would be very usefull (see demo)

2. To reach a version a few milestones are needed. A customer giving feedback knows about the version (version 1 is already in productive use, version 2 is the development), but for sure he cannot (and should not) target the milestones with his request.

So he can post a ticket to the correct version, the team decides to which milestone this ticket must be assigned.

Other example:

You build a website. following stages (milestones) for version 2.0

1. planning
2. programming of the backend
3. programming of the frontend
4. get content from customer
5. content into cms
6. beta
7. launch

Here some of the milestones can be started and worked on together independend (2 - 4), but 5 cannot be started bevore 2-4 are finished

What would be really helpfull would be a integration of the Gantt-project or similar functionality. So if one task needs longer all other timings get adjusted.

Usual szenario: you get needed data from your customer 1 week late. So you adjust and can hand him out the new timing schedule.

Hi all,

I'm bumping this thread up because I think it's a pertinent discussion.

Like some others, we use Redmine not only for software projects but also as a more general PMS.

We're also missing a milestone functionality and I don't think versions can replace it. Milestones are somehow places on a timeline, phases of a project like in the traditional model of PM theories:

• Project initiation stage;
• Project planning or design stage;
• Project execution or production stage;
• Project monitoring and controlling systems;
• Project completion stage.

Or even in the waterfall model that's used in software development:

1. Requirements specification
   2. Design
   3. Construction (AKA implementation or coding)
   4. Integration
   5. Testing and debugging (AKA Validation)
   6. Installation
   7. Maintenance

Software versions are not phases of a process, they can be worked on in parallel, you can open issues for all versions, etc...
Not exactly what we need as we'd like to be able to place due dates at the project level, for the planning phase, execution/development/production/testing phase, delivery, closing etc...

Really, for example I don't see how installing a project's final product by a customer and doing acceptance tests can be considered "versions"...

I like the idea of having Versions and Milestones.

If we have to stick to Redmine's versions, then at least we should be able to lock them so that nothing new can be added to phases that are finished, to milestones that are in the past, and we need to know in which stage of a project we actually are (timeline, gantt,...).

I've seen a Feature Request that could address a part of the problem:
http://www.redmine.org/issues/1245

Eric

It is a pity that REDMINE does not have the milestone function.
The Version is not help for my using on the none-sw project.

First, sorry for hijacking this rather old thread. And sorry or forcing you to read such a long blob of text. But I try to keep it to the point...

I think versions as currently implemented in Redmine could indeed be used as milestones or iterations / sprint.

However, after reading this thread as well as the comments on the issues #724 and #4178 I conclude for myself that we should split up that functionality into separate parts. I am willing to create a plugin and/or a patch to Redmine, once we can agree on a desired feature set.

From what I have read, learned and experienced till now, I think, the following features and concepts are suitable to enhance Redmine to a full-fledged project planning suite usable for any type of project.

Versions are mainly used in engineering or software projects where multiple versions of a product are maintained at the same time.

• Issues can today be assigned to exactly one version. Is this enough? What about a bug present in multiple versions of a software product? What about a tree-like inclusion, such as "Version 2.3 includes Version 2.3.1 and 2.3.2". It would be nice, if I could e.g. express a bug to be valid from version 1.3.7 till 1.3.11 where it was finally fixed.
• Versions can be closed and locked today. This can be used as a kind of life-cycle. However, I think we should allow to maintain a complete product life-cycle like Development, Beta, RC, General Availability, Phase Out, EOL. These statuses and the transitions between should be individually definable like the ticket statuses and the workflow allow today. They should also change the version behavior (like closed or fixed does today). E.g. there could be no new features on a version in Phase out state. The end of each of the life-cycle phases of a version could represent a milestone (see below)

Milestones are a mean to structure a complete project into small, usable parts. Traditionally, a milestone is thereby tied to something fix like date, a certain budget, or a given feature set. A milestone is just the fixed point at which the project phase leading to the milestone is finished.

Milestones are normally defined before the start of a project and are used to define and check the progress of a project. They can depend on each other, thus implying a certain serialization but it is still possible to perform the actions leading to the milestones in parallel.

To be able to assign issues and time entries to a milestone (or better, to its phase), we should introduce the concept of a project phase

• As Milestones are a traditional mean to structure a project (mainly used in serial models like waterfall or the V-model), they should be present in places like the GANT-chart, the time reports and the roadmap.
• Milestones should be usable without requiring versions. E.g. a graphic design project can be finished after some time. It could have the milestones Contract sign-off, Got Customer Input, Initial Draft, Final Draft, Project finished. In this example all milestones are serialized so work is done only in the current phase leading to the next milestone. However, issues could be assigned to the current or any later phase .
  • The GANT chart could be used to reflect the current time planning. So if new issues with estimated time are assigned to a project phase, the milestone date is going to move.
  • This however depends on the number of person-hours done per real time (and maybe some overhead). So, if I assume 4 person hours on an issue but have two people working on it, the milestone moves 2 hours (a quarter day) behind.
• As state above, there should be one or more active or current phases where work is done. Once the phase is closed and its respective milestone is reached, no new issues or time can be assigned to the phase.

• From what I can observe there are already some plugins for Redmine which allow to select issues to work on and keep a personal schedule for each of the project members. So we should look out for integration points here.

Conclusion. After writing this (and reading it again), I think, the Versions as implemented today in Redmine resemble milestone phases much more than they resemble real product versions as defined above. So I think we should try to transform the current versions into real phases with a milestone at the end and introduce a new concept of versions as defined above.

What do you think?

Disclaimer. My perspective on a project currently was mainly the of a developer. So it is very well possible that I miss crucial functionality needed by the project manager on the other side of the table. If anyone of you has any further insight, please let me know.

This perfectly fit my needs and this is really an important feature to me. Thanks for planning to develop this!

Holger, I really like your definition of a milestone being a fixed point in time (for example) that marks the end of a phase in a project. It makes it clear that a software version is neither a phase nor a milestone.

You made a pretty good synthesis of the definitions for phases and milestones of a project, as well as versions.
To make redmine more open to any type of projects without finding ourselves stuck somewhere in each others management process would indeed require such fine definitions (and their implementation).

If I considere our own PM needs (for our software and non-software projects):
It would be nice if we could define phases and milestones in a project without requiring versions.
When we use versions, it would be nice to be able to define phases and milestones to the different versions in that project.

You also pointed out an important thing with issues actually being assignable to a single "version" only...
Though, the tree-like inclusion you propose wouldn't fit with our versions numbering/naming. It would be better if we could select multiple versions in a list.

But is it possible to implement all these features as a plugin?
Or wouldn't a patch require deep modifications in Redmine's core?

Well, is it feasible to implement such features?...

Eric

Redmine has an open core, so everything can be implemented as a plugin first, and then maybe ported into the core.

I have some additions to my earlier proposal:

• After skimming over my project managements notes from the uni, I saw that milestones can be at the beginning, at the end, and also somewhere in the middle of a phase. To ease the definition of a phase, I think, we should allow milestones to be at the beginning and the end of a phase only (defined by a specific user-defined date or floating from its issues) only.
  • What should be done, if I define a fixed date but am not able to match that date, i.e. have still open issues at the end. Should the following/dependent phases automatically moved? How is this implemented in MS project et al.?
• Versions and milestones/phases should indeed be independent concepts, which can optionally be defined together. So, if I define some versions, I should be able to connect them with phases or certain milestones derived from the phases. But I should not be required to do so.
• Regarding the version tree: I think, the feature itself is rather useful. It has to be further thought through though :). I think, the tree should be freely definable and not be tied to a specific naming schema (implemented like the project tree in trunk today). The inheritance could then be implemented to work in three ways:
  1. Down the tree, so that issues assigned to a top version also apply to all the child versions, or
  2. Towards the top, like the issue display inheritance works today with projects, so issues assigned to versions at a leaf of the tree are also displayed in less granular versions
  3. Both of the above
  4. Not at all
• Having multiple versions to assign an issue to would be a first step towards more usability though.

I I find time over the holidays, I try to create a first prototype or at least a screen mockup.

Pfew, there are so many points of view on that subject that about every situation and management method should be envisaged! About everything should be tie-able to about everything...

It seems the most "versatile" item are versions because they can be worked on in processes that can be parallel, iterative or cycling. Indeed we should be able to tie versions to phases/milestones but I'm still wondering if the inverse (that is defining phases/milestones for versions as I proposed) is such a good idea. Well, it would make (some) sense in case of parallel versions. Though, parallel versions are versions of a same product (if not, then they should be different projects). As I see it, every project is made of phases (e.g. initiation, development, EOL, etc), whatever the adopted method is, so parallel versions in a project should belong to one (or more) phases of that project... Sorry, I'm thinking loud here and I may be wrong... say it's brainstorming!

Regarding overdue dates, I think they should be handled on a case by case basis because sometimes you can slip the whole project due date but sometimes you can't and subsequent phases (e.g. software testing ;-) must be shortened, or they must begin while previous phase is still open. We should indeed be informed on the overdues, but we should then decide what to do (possibly after a team meeting, a discussion with the stakeholders, etc...)

As for the version tree, insofar as we can organise our version tree as we want, it'd be fine...

But are you envisaging to modify the meaning and the behavior of actual 'version' field in Redmine? No risk of breaking the operation of some other plugins, for example?..

Eric

Bless you all. This might be a long one so buckle in.

I'm quite glad I decided to scan the list tonight. For the last year, Peter & I have been preparing our budget plugin to become a contract management plugin. The goal is to help anyone running a project to effectively execute the terms of the contract with the client. To create accountability for project managers the way issues do for technicians.

All of our contracts have three fundamental items:

Scope (deliverables / issues)
Time (milestones)
Budget (deliverables / time * rate plugin)

As part of this plugin we have been examining the role that milestones play and how they should be implemented. It would seem that we have landed in the exact same place as you folks (holger and eric). We decided that a milestone is really best defined by something that needs to happen on or by a specific date. Almost a calendar date tracked by the system. It can be complicated and be tied to a number of actions like a version, or as simple (and critical) as an invoice date. We split milestones into three categories:

Financial
Event
Client Dependency

We probably could have gone significantly more detailed but decided to split them by who would need to act. Financial is dealt with by the ap/ar folks (or pm if they wear that hat too). Client dependency by the account rep (or pm if they wear that hat too). Event is a catch all for things the pm is accountable for. I'd be curious on your thoughts. I am going to include our milestone scope notes below. They are a bit long but you might find them useful. I am also attaching a working wireframe of our contracts plugin. It is a doozie to digest and has quite a lot of working parts, but about 3/4 of the way down the page you will see our milestones section.

Question: Where and how are you planning to use milestones? Should they show in the Gantt and calendar? Where else? Also let me know if I should create a new thread for the contracts plugin and invite discussion.

Milestones Spec

• Title
• Date
• Description (Wiki Formatted)
• Type (Financial, Event, Client Dependency)
• Complete (checkbox or button)
• Amount (if Financial)
• Invoiced / Paid (checkbox or button for financial user)
• PM Alert (emails Managers with link to Contract)
  o End of Day (default)
  o Beginning of Day
  o 1 Day Before
  o 2 Days Before
  o 3 Days Before
  o 4 Days Before
  o 5 Days Before
  o 1 Week Before
  o 2 Weeks Before
  o 3 Weeks Before
  o 4 Weeks Before

Milestones should generate an ical calendar.

Financial Milestones should also be globally accessible to financial people in a central location. (Phase II) Financial milestones should only be available to admins and managers. All other milestones are available to anyone on the project.

Ajax Checkbox / Button
The Milestones can be marked as Approved/Complete by checking the box in the Contract Overview. This should happen without page reload. This can be done using images or a checkbox.

• Incomplete milestones can be clicked.
• The button/checkbox turns into a loading graphic.
• When loading is complete, the button/checkbox reappears as checked.
• The complete milestone can be toggled... the same loading process applies in reverse.

Dynamic Milestones

Dynamically generated milestones should exist for the following.

• Deliverable Start Date???? Not sure we care.
• Deliverable Warranty Date
• Deliverable End Date
• Contract Start Date
• Contract End Date
• What about financial milestones??? Like monthly milestones for monthly deliverables?

On that note, i do also want to point out that the term "Milestone" is derived from markers on the side of the road that allow you to gauge where you are. I've always seen Milestones as markers in time. You can use them for PM events, financial events, external events, or really anything that you and everyone (or some subset of people) on your team need to be coordinated about.

http://en.wikipedia.org/wiki/Milestone