Re: Highsmith article on "Release, Milestone and Iteration Planning" (was Re: Nesting weekly iterations within monthly sprints)
- On Wed, Dec 03, 2003 at 05:29:00PM -0000, slightlynew wrote:
> Brad,Jim Highsmith said it was in an "e-advisory" newsletter from
> > I remember a short article written by Jim Highsmith entitled
> > "Release, Milestone and Iteration Planning" which described
> > the need for all three of those things in an agile project
> > (i.e. a Release plan that has both milestones and iterations
> > planned within it) where the iterations are smaller-grained
> > than the milestones
> I was in a discussion of this topic only yesterday. Can you
> provide a link to this article?
the cutter consortium. He gave me permission (via personal
email) to post the newsletter to the list provided I did so
in its entirety (including the ads). Here it is after my
email signature below.
Brad Appleton <brad@...> www.bradapp.net
Software CM Patterns (www.scmpatterns.com)
Effective Teamwork, Practical Integration
"And miles to go before I sleep." -- Robert Frost
Welcome to the Agile Project Management E-Mail Advisor, a
weekly electronic briefing from Cutter Consortium's Agile Project
Management Advisory Service.
AND ITERATION PLANNING
by Jim Highsmith, Director, Agile Project Management Practice
When people first learn about agile or iterative development, they
often think just in terms of short timeboxed iterations. However,
there are two components to iterative planning -- the short iterations
and the use of features rather than tasks. Basing plans on the
product's features (and its architecture, which is instantiated by
features) keeps the project team and the product's customers
synchronized (because the customers understand the product
even though they may not understand the technical activities). It also
focuses the team on delivering the product rather than focusing on
intermediate documentation artifacts.
It's not that documentation artifacts are not useful; no one would
consider building, say, an airplane or an automobile without extensive
documentation. The problem is not documentation per se but that
project teams often get lost producing intermediate artifacts that
have little bearing on the final product. Feature-based planning
attempts to overcome this problem.
Many project managers can't fathom a 12-month project broken
down into two-week iterations -- and in some ways this is
understandable. Once projects go beyond four to five months, they
usually need interim checkpoints at two-week intervals and at the
project's end. Larger projects that employ distributed teams or
vendor-supplied components will have problems synchronizing
every two weeks. So, many projects will require three (or even
more) levels of iteration.
The longest period is the release cycle. Products are generally
released to customers periodically -- once every year or 18
months, for example. As such, "release" implies a release for
On the other end of the spectrum, an iteration is used by a
development team to focus on small increments of work. In agile
software development, an iteration might be two weeks (XP), 30
days (Scrum), or slightly longer for some projects. If you're building
an airplane, the iterations will surely be longer.
Milestones are intermediate points -- usually from one to three
months. Milestones can have both a project management function
and a technical function. From a project management perspective,
milestones provide a chance to review progress and make more
significant project adjustments. For example, while most agilests
recommend project mini-retrospectives at the end of each iteration,
most would actually employ them every two to three iterations if
the iterations were short (two weeks). Milestones can also be used
as major synchronization and integration points. For a product that
has both hardware and software components, monthly (or even
longer) synchronizations may be entirely adequate. On the other
hand, if less-frequent synchronizations are going poorly, it might
indicate that the synchronization should occur more frequently.
Iterations produce acceptance-tested features. The goal is to have
a partial-feature product that could be deployed at the end of any
iteration -- that is, the features, testing, documentation, and other
product deliverables could be packaged up and deployed. Iterative
and incremental development are differentiated by this actual
deployment. In some types of software development -- many Web-
based systems, for example -- this goal can be achieved. By early
deployment of partially completed products, early returns can
boost ROI, and early feedback from customers can enhance the
development during subsequent iterations. For other products
(including a number of software products), this goal of being able
to deploy at any iteration keeps the team on its toes but won't
always be achievable. If a competitor has a product on the market
with a certain capability, it won't be feasible to deploy your product
until it has comparable capability.
Some people think agile development gives them an opportunity to
dive in and build (or code, in the software arena). They condemn
agile methods, saying they spend little or no time on early
requirements gathering or architectural issues. On the other hand,
there has been an equally negative reaction to months and months
of planning, requirements specification, and architectural
philosophizing. There is obviously a balance point, but many
arguments imply there is no middle ground. Iteration 0 is a practice
to help teams find that middle ground. The "zero" implies that nothing
useful to the customer -- features, in other words -- gets delivered
in this time period. However, the fact that we have designated an
iteration implies that the work is useful to some other stakeholder.
Though the range of issues can be broad, the outcome is the same --
some projects require more extensive initialization work than others.
The key to effectively utilizing Iteration 0 is to balance the possible
advantages of further planning with the growing disadvantage of
lack of customer-deliverable features. There are always tradeoffs.
If the cost of a technical platform change is very high, then additional
work to improve the odds of an initial correct decision may be
justified. Iteration 0 for a next-generation jumbo jetliner will be
much different than that for a standalone software product.
Iterative planning is an integral part of agile project management;
however, there are many variations on the theme that are determined
by the specifics of a particular product or project. There isn't a
single right way or a single iteration length that works for every
-- Jim Highsmith, Director, Agile Project Management Practice
Learn more about iterative planning and agile project management
when you bring Jim Highsmith and his highly popular *Agile Project
Management: Innovation in Action* workshop into your training
room! For more information, visit
http://www.cutter.com/workshops/22.html , call David Gijsbers
at +1 781 641 5104 or send e-mail to david@....
The Cutter Consortium report *The Politics of Software Testing*
explores approaches for performing just enough testing to create
quality software without compromising your IT budget. It reveals how
agile and risk-based testing approaches can provide a practical and
cost-effective solution to your software testing challenges.
This report also explains how to develop an enterprise-wide,
structured approach to testing that incorporates business risk
management. With this approach, you'll conduct more consistent and
rigorous testing, realize quicker returns on your investment and
continually reduce testing costs.
Order your copy of *The Politics of Software Testing* today for just
US $249 (US $264 outside North America). Order online at
http://www.cutter.com/bookstore/testing.html , or call
+1 781 648 8700, send a fax to +1 781 648 1950 or send e-mail
If you'd like to comment on today's Agile Project Management
E-Mail Advisor, send e-mail to apm@..., or send a letter
by fax to +1 781 648 8707 or by mail to The Agile Project
Management E-Mail Advisor, Cutter Consortium, 37 Broadway,
Suite 1, Arlington, MA 02474-5552, USA.
To unsubscribe to the Agile Project Management E-Mail Advisor,
send e-mail to majordomo@... and include the message
"unsubscribe agile_list your-e-mail@..." in the body of
the message. Please use all lowercase letters and verify that your
e-mail address is correct. Do not include anything but the message
"unsubscribe agile_list" and your e-mail address in the body of the
message. If you have any problems, please contact Ron Pulicari
(c) 2003 Cutter Consortium. All rights reserved. Unauthorized
reproduction in any form, including forwarding, photocopying,
faxing and image scanning, is against the law.
To sample our other weekly E-Mail Advisors, you can register at