Software Engineering Stack Exchange is a question and answer site for professionals, academics, and students working within the systems development life cycle. It only takes a minute to sign up.
Sign up to join this community
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?
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.
I think the purpose of milestone to see big picture of release/feature candidate program/app (or anything else which team develop).
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.
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.
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.
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. :)
