When working with clients on a software development project, with a project of any significant size, we are likely to be using an agile development approach.
One potential conflict can arise when we start to talk about milestones, putting specific release plans, or other activities into the calendar.
This can scare many agile enthusiasts. Some consider the very act of trying to introduce milestones, as a negative behaviour, closely associated with deadlines and something that is anti-agile.
For me, I think there are a lot of negative behaviours that are becoming all too common in the name of an agile development project. I would much rather see development that is truly aligned with all needs of the business, and that has to include the strategic use of milestones.
Milestones, when managed correctly, are critical to a project’s success. Forecasting activities and the ability to plan related businesses activities, such as sales, marketing, implementation planning all need to be considered during a development project.
Considering milestones in an agile world
There is a way that milestones and agile development can work well together. There doesn’t have to be a source of tension of conflict.
The first point I would like to make is that milestones should be viewed as planned business activities, as release goals, not hard and fixed deadlines.
If we make the mistake of thinking of milestones as fixed deadlines, fixed points in time, and fixed scope, then it’s easy to see why there could be conflicts and problems in the development.
If we view these milestones as goals, then they can have a massively positive impact on the development team.
In a Scrum development model, every sprint should have a clear goal. By having milestones in place, we can sure that each and every sprint goal leading up to any milestone is directly contributing to the larger milestone goal.
The goals defined serve to focus our planning and work.
With a Scrum model, when prioritising the backlog, and planning work items for any sprint, again, we should very critically evaluate each work item as well as acceptance criteria against the next milestone.
We should ask ourselves whether the item itself contributes to the next goal.
We should ask ourselves whether the acceptance criteria or scope of each work item contributes to the next most immediate goal. It could be that whilst the final version of a feature may work a particular way, we only need a subset of that functionality in order to address the points needed for the next goal.
Goals to focus, not deadlines to fear
To summarise, rather than fearing milestones and viewing them as deadlines that can cause unnecessary stress or quality problems, we should see them as goals along the development timeline.
These goals will help us plan and manage our work ensuring that we can maintain focus and make product decisions in the right context.