Agile Zone is brought to you in partnership with:

Alex Miller lives in St. Louis. He writes code for a living and currently work for Terracotta Tech on the Terracotta open-source Java clustering product. Prior to Terracotta he worked at BEA Systems and was Chief Architect at MetaMatrix. His main language for the last decade has been Java, although Alex have been paid to program in several languages over the years (C++, Python, Pascal, etc). Alex has posted 43 posts at DZone. You can read more from them at their website. View Full User Profile

Software Rhythm Part 1: The Opening

09.10.2008
| 15068 views |
  • submit to reddit

What do we build?

The opening phase of a release cycle is consumed with figuring out what we are going to build. Generally the inputs to this process come from a variety of sources: product managers, sales, engineering, customers, etc.

Some group of people (usually led by product management) has the ultimate decision on what set of features will be included. It’s an inevitable fact that release dates are fixed - whether to match business cycles, financial calendars, holidays, boss’s vacation, whatever. That bothers some people but I gave up worrying about it years ago. If the end date is fixed, it’s necessary to choose a feature set for the release that can fit in the time available. 1

To figure that out, the engineering team needs to be involved to do some up-front analysis and provide rough estimates for each feature. To be able to size features, you need certain information from product management: requirements and use cases. The fidelity of these will vary greatly from organization to organization. One of the most important things you can do is to make sure that everyone involved in planning agrees on what you are building. If not, in the words of Walter Sobchak in the Big Lebowski, “you are entering a world of pain”.

Sometimes, for new or innovative features, you may just have a problem and no known solution. In that case, you may need to do some spikes to determine some options and choose one. The more innovative the feature is, the more time you will need to evaluate it. In fact, you will likely be doing this analysis throughout the release. It may even fail. That’s the risk of doing innovative work.

Once you have picked the actual release features, it is absolutely essential to assign priorities to your feature list, preferably ranking them from most to least important. This is necessary because those estimates you created suck. That’s not your fault - all estimates suck. Ranking them now makes it clear what will be dropped first when it turns out you forgot that you need to rewrite a bunch of stuff when you upgraded the version of some library to get a new feature.

Published at DZone with permission of its author, Alex Miller.

(Note: Opinions expressed in this article and its replies are the opinions of their respective authors and not those of DZone, Inc.)

Comments

Alexander Shirkov replied on Wed, 2008/09/10 - 5:57am

Nice article, Alex. Waiting for next parts.

Comment viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.