A lot of issue trackers support something called "milestones". I've never found a use for them. It seems that milestones are only useful when you do big, scheduled pushes, but not if you roll out new features and bug fixes as they're completed.

When/how would you use milestones to organize agile development?

  • To answer in two words, "release planning". – rwong Mar 15 '15 at 1:21
up vote 8 down vote accepted

Some agile team use them to communicate with the customer when he can expect to have a new version of the software (even if that version is incomplete). This allow the customer to plan the migration to the new version, before it is released.

For example, for a software developped in an agile way and released every 6 month, the following could be the milestones.

Alpha 1 - December 19th

The first set of feature arriving, usually buggy. This is useful for trying them out and giving feedback

Alpha 2 – January 23rd

Next set of features, plus some fixes for the feedback in Alpha

Beta 1 – February 27th

All the feature for the current version are there, and no one will be added until the final release. New development will be in the next version. You can still suggest some small tweak to existing one though.

Final Beta – March 27th

The behavior of the feature is completely frozen, unless a critical flaw is found. Only bug will be fixed.

Release Candidate – April 10th

The final version to be released. No bug are supposed to be found here. If some are found, a new release candidate is created.

Final Release - April 17th

The supported version is released to the general public, since no bug have been found the release candidate

(Note : I didn't follow exactly the ubuntu semantic here)


With that release plan in hand, a customer can plan ahead. If a new feature is really expected, he can test it during the alpha stage to ensure that it fit what is required. Programmers can start experimenting with the new feature during the beta stage. Regression testing can start during the release candidate stage.

Knowing when the software will be released and what will it contain is hugely important for a lot of user. Using milestone, you can know what is going to happen and when. The agile mindset is still there, manifested by the fact that before a certain date the feature set is variable. This is unlike the waterfall way, where you plan both the features and the release date. And of course the next version isn't set, again unlike the waterfall method.

So to answer your question : In agile, milestone are used to indicate when important decision and action are going to be taken, even if those actions and decision themselves can change.

  • 1
    +1 It's all about the customer. Sometimes the customer is your own marketing department, other teams like ops that need to support your code. – Patrick Hughes Dec 28 '13 at 2:14
  • By "agile" and "roll out" I actually mean we deploy to production once or twice a week. There are no alphas, betas, or release dates. – mpen Dec 28 '13 at 3:17
  • 3
    Well then, your milestones are already set for you : each deployment is one! As for the question "is it useful for me to use the milestone feature of my tool" then the answer is probably no for your case :) . Though, if you were to do something out of the ordinary -like the migration of your whole database to a new system-, then you could set a milestone for that, since it would be an important change that require the coordination of more people than usual. – Laurent Bourgault-Roy Dec 28 '13 at 4:33
  • 1
    @Mark We basically do something similar to what Laurent said in that last comment: For us, every sprint has its own milestone, even though we don't release every sprint. It makes for much easier organization of cases. – Izkata Dec 28 '13 at 7:36
  • That's fair. I'm just thinking about how I might use them to divide work into meaningful chunks. I'm worried that having one per week might be a bit excessive and a waste of time to manage. – mpen Dec 28 '13 at 19:29

I think the purpose of milestone to see big picture of release/feature candidate program/app (or anything else which team develop).

It could be useful for developers/workers:

I can imagine an issue tracking system with many task, bugfix, feature etc. It has milestone field. I think if your team has two milestone and only one prefer your customer, that your team start do these task, or fix these bugs or develop these features which are marked with this milestone.

It could be helpful for managers:

That is very important thing which release will be release to production environment of customer. In this case the milestone is release to production environment. But the milestone could be mark off package of features.

It could be helpful for customer:

May be, the customer want to show this program, or programs bugfixed version, or new features of program for another person/organization. So, the customer need stable version of program. I think when program achieve this milestone It would be stable and releasable.

If the customer, managers and workers checks bugs, taks and features in issue tracker, I think It betters know milestone of them.

When you start a development project - regardless of the methodology -, you should always have a rough plan you are following, about the "must-have" features, core features, "really-important" features you want to develop, and in which order. Ideally you also have a vision about the realization time. Writing down this plan in form of milestones makes this transparent for anyone involved in the project.

In any kind of real project, this plan has to be adapted to reality from time to time. Maybe one has to reassign features to different milestones, sometimes one identifies things as less important as thought to be beforehand, sometimes one has to add some missing requirements/features to your development plan, and sometimes one may have to change the list of milestones itself. IMHO the main difference between a "waterfall" and a "agile" project is that in an agile project you are honest to the customer about the need for adaption from day 1. In waterfall projects, you have no built-in mechanisms to change the plan before the product is "ready" (and probably faulty). In agile projects, it is an explicit duty of the customer to help the development team to adapt the plan to reality - continuously throughout the whole project, every week or even more often.

There is also a difference at which time you analyse the gory details of the requirements for any milestone. Waterfall projects tend to over-analyse every feature of each milestone beforehand, in agile projects you will typically analyse only one feature of the next milestone in-depth.

So I would say especially in agile projects a milestone plan helps the stakeholders to understand that the development is not completely arbitrary or random, and that you still follow an overall plan.

A different question is if you need the "milestones" feature from your issue tracker. A milestone plan is typically just a document in your favorite document format, so you can easily show it to any stakeholder of your project. You have to decide for yourself if it brings you any benefit to put the milestones into your issue tracking system, or if you prefer to maintain it in a completely different way.

You already answered your own question. "... useful when you do big, scheduled pushes..."

Since you're only doing maintenance and update work then milestones don't make a whole lot of sense. Except: even when choosing what features to iterate on it's nice to have an overview of where all the features are heading to keep agile development from spiraling out of control and for the project to feel cohesive.

Milestones give a point to measure how well long term goals are being met and a point to stop and consider what direction future iteration should follow.

Milestones are useful for customer involvement, e.g: When developing a prototype, a milestone will allow the team to know what work items must be completed in order to have a prototype ready for presentation.

It's also useful for evolutionary implementations as well as providing an audit trail of development. In a team I worked in previously, the team leader would fork off of the main repository to keep a version of the product at that specific milestone. This allowed us to show upper management the evolution of the product and to justify budget.

Every Feature is a milestone, by definition

an action or event marking a significant change or stage in development

The usefulness of tracking individual or groups of milestones for your project and your team and your customer is primarily a matter of taste/style

Some teams/customers like checking off milestones every day or so, others are content to do so less frequently

ADDENDUM: The key word is 'significant' - which is subjective. Your milestones may vary. :)

  • 1
    Can't say I agree with that. If you're developing tiny new features every day, they aren't really significant. If they fit within a single ticket/issue, why bother creating a milestone for it? – mpen Dec 28 '13 at 7:02
  • By definition? BS! A milestone marks a project stage, where a predefined state is considered arrived. It is therefore typically composed from a number of features and/or bug fixes. Although calling a single feature a milestone would be theoretically possible, such would be merely kind of an academic (read: non-relevant) edge case. – JensG Dec 28 '13 at 14:27
  • @Mark: it sounds to me like you do agree - that it's a matter of taste/style ;) – Steven A. Lowe Dec 28 '13 at 16:18
  • 1
    The point is that if your milestones are as granular as your tickets, then they don't serve a purpose. Milestones should break the work up into larger chunks. – mpen Dec 28 '13 at 19:27
  • 1
    @Mark: of course. Personally, i use milestones only for things that the client signs off on, but that's a subjective choice made in cooperation with the client and team. Sometimes it is a single feature, sometimes it's a collection of related features within an iteration. – Steven A. Lowe Dec 29 '13 at 18:36

Your Answer

 
discard

By clicking "Post Your Answer", you acknowledge that you have read our updated terms of service, privacy policy and cookie policy, and that your continued use of the website is subject to these policies.

Not the answer you're looking for? Browse other questions tagged or ask your own question.