Dr. Dobb's is part of the Informa Tech Division of Informa PLC

This site is operated by a business or businesses owned by Informa PLC and all copyright resides with them. Informa PLC's registered office is 5 Howick Place, London SW1P 1WG. Registered in England and Wales. Number 8860726.


Channels ▼
RSS

Design

Agile on a Fixed Budget


Variable Scope

When the requirements for a software development project are allowed to vary, your best strategy is to work in short, time-boxed iterations delivering working software on a regular basis. Working software provides concrete feedback to your stakeholders, enabling them to determine whether what you have built meets their needs, and if not, to direct you accordingly. A common agile strategy—found in methods such as Extreme Programming (XP), Scrum, and Agile Modeling—is to work on requirements in priority order as defined by your stakeholders and to allow stakeholders to change the requirements as the project progresses. Working in priority order enables you to maximize the return on investment (ROI) as defined by your stakeholders yet remain flexible enough to build software that meets their actual needs. Figure 2 shows the OpenUP's (www.eclipse.org/epf) strategy for treating all work items, including requirements, in this manner. It adopts Agile Modeling's strategy of "Model a Bit Ahead" when you have complex work items to address in the near team, enabling you to increase your team's velocity by paving the ground ahead of it.

[Click image to view at full size]

Figure 2: Treating work items like a prioritized stack. Adoption rate of agile techniques.

A common problem with allowing requirements to change throughout a project is that stakeholders will try to motivate you to do more than you actually can in an iteration, putting you at risk. If you actually have the time to implement the feature then by all means do so, but if not then either ask them to wait until a coming iteration or to remove an equivalent amount of work from the current iteration. An analogy that I like to use is a shopping cart. If you have $50 to spend and you've already filled up your shopping cart with $50 of stuff, to add a $4 bag of cookies into your cart you need to remove at least $4 worth of existing food. Stakeholders understand this comparison, and once they see that you deliver working software each iteration, they quickly recognize that they eventually will get the functionality that they want.

The implications of fixing the scope early in a project can prove to be quite dire. People are not very good at defining what they want up front, so no matter how good your business analysts are, it's incredibly unlikely that you'll write an accurate, detailed requirements specification at the beginning of the project. Even if you could get the requirements right, they're going to change anyway based on changes in the marketplace, decisions by senior management, regulatory changes, and so on. The earlier your requirements are "firmed up," the greater the risk of building something that your stakeholders don't actually want. My April 2007 newsletter entitled The Dire Consequences of Fixed-Price IT Projects (6) explored these problems in greater detail.


Related Reading


More Insights






Currently we allow the following HTML tags in comments:

Single tags

These tags can be used alone and don't need an ending tag.

<br> Defines a single line break

<hr> Defines a horizontal line

Matching tags

These require an ending tag - e.g. <i>italic text</i>

<a> Defines an anchor

<b> Defines bold text

<big> Defines big text

<blockquote> Defines a long quotation

<caption> Defines a table caption

<cite> Defines a citation

<code> Defines computer code text

<em> Defines emphasized text

<fieldset> Defines a border around elements in a form

<h1> This is heading 1

<h2> This is heading 2

<h3> This is heading 3

<h4> This is heading 4

<h5> This is heading 5

<h6> This is heading 6

<i> Defines italic text

<p> Defines a paragraph

<pre> Defines preformatted text

<q> Defines a short quotation

<samp> Defines sample computer code text

<small> Defines small text

<span> Defines a section in a document

<s> Defines strikethrough text

<strike> Defines strikethrough text

<strong> Defines strong text

<sub> Defines subscripted text

<sup> Defines superscripted text

<u> Defines underlined text

Dr. Dobb's encourages readers to engage in spirited, healthy debate, including taking us to task. However, Dr. Dobb's moderates all comments posted to our site, and reserves the right to modify or remove any content that it determines to be derogatory, offensive, inflammatory, vulgar, irrelevant/off-topic, racist or obvious marketing or spam. Dr. Dobb's further reserves the right to disable the profile of any commenter participating in said activities.

 
Disqus Tips To upload an avatar photo, first complete your Disqus profile. | View the list of supported HTML tags you can use to style comments. | Please read our commenting policy.