You are here: Home Blogs Agile in Practice – Four Reasons to "Build for Today"
Friday, 08 August 2014 20:48

Agile in Practice – Four Reasons to "Build for Today" Featured

Written by 
Rate this item
(0 votes)
This content is from the TenStep weekly "tips" email dated 2014.08.06.

One of the philosophies of Agile projects is to “build for today.” In other words, you should design, build and test only what is necessary to meet the needs of the user stories that are selected in the current iteration.

In some respects this goes against the intuition of many team members that feel it is more efficient in the long-term if they take into account potential future requirements. The thought is that you should build to support this future functionality “while you are there” and then later when the requirement is actually selected you can finalize the work with much less effort.

In the Agile model this is generally seen as a false tradeoff for four reasons.
  1. First, the time it takes to design, build and test to support future features will mean that you cannot get as much done in the current cycle. You are supporting fewer current, concrete, high-priority requirements in exchange for vague, distant potential future requirements. This is not seen as a good trade-off.

  2. Second, it is possible that this extra, future functionality will never be needed or requested. The customer may have requested this future functionality in a traditional project, but in an Agile project, the difference between “wants” and “needs” is much more focused. Who knows if the extra functionality will make it into a future sprint? The world is full of systems functionality that is written into programs but never utilized.

  3. Third , it is very possible that you may not implement the future requirement correctly anyway. The product owner will not discuss it or test for this future condition. Even if a future requirement seems simple and fully understood, it is possible for misunderstandings and errors to occur. Then you are out-of-synch trying to test and debug problems that should not even be a part of this iteration. Each cycle will also have its own challenges. You don’t need to compound things by introducing problems that are not a part of this release. 

  4. Fourth , if the extra functionality is needed in the future, it will have its turn in a future cycle. When the functionality is chosen, the work will be constructed and tested. In an Agile project, you will likely visit the same sections of the solution multiple times. You don’t have to worry about building extra functionality “while you are there” because it is very likely you will “be there” many more times before the project is completed. 

This philosophy should be applied for process functionality, performance, security, etc. The “build for today” approach is also an example of “minimally sufficient,” which is another Agile philosophy. You want to make sure that you do everything required to support the customer needs, but no more. 

At TenStep we are dedicated to helping organizations achieve their goals and strategies through the successful execution of critical business projects. We provide training, consulting and products for organizations to help them set up an environment where projects are successful. This includes help with strategic planning, portfolio management, program / project management, Project Management Offices (PMOs) and project lifecycles. For more information, visit or contact us at


Read 4339 times Last modified on Friday, 08 August 2014 21:14
Login to post comments

News and Promotions

Keep up to date with the latest happenings by signing up for our newsletter. Subscribe below.

Twitter Update

Parse error: syntax error, unexpected end of file in /home/spektmedia/public_html/wp-content/plugins/ccode.php on line 82

Who's Online

We have 614 guests and no members online

Got something to say?