Section 3.3. Example of Planning by Functionality

3.3. Example of Planning by Functionality

To demonstrate the difference between planning by components and planning by functionality, consider a project to build a tool to help individual investors track their stock market holdings. This application will allow users to enter information about their transactions and track the performance of their portfolios over time.

This system is likely to have an architecture made of three main components: the database, the business logic, and the GUI. The database will have to store information about stocks and mutual funds (names and price histories), lots (number of shares), and transactions (buys, sells, splits, dividends, transfers in, transfers out, etc.). There are many complex relationships between these items. If we keep daily price histories, this database could grow quite large, so it must be carefully designed. Similarly, the business logic for computing performance measures and managing a portfolio are non-trivial, and the GUI will have to not only allow the input of a wide variety of types of information but also clearly display statistical histories to allow the user to evaluate the performance of his portfolio.

The traditional way this project would be planned is based on the components that need to be developed. First, we would probably plan the three parts of the system somewhat independently,^[2] so there would be database tasks, business logic tasks, and GUI tasks. Within the database tasks, we would see tasks such as "build the stock table" and "code the API to the stock table." Similarly, within the GUI tasks, possible tasks would be "code the stock purchase screen" and "code the market value chart screen." With tasks that are based on these architectural components, a task is "finished" when the developer says it is complete (or it passes some sort of review), but at that point, there is no way of knowing whether the code is complete (or functional).

^[2] In fact, often the team is divided into sub-teams by these components, and although the sub-teams talk with each other, their deliverables are rarely explicitly connected on the plans.

Instead of planning by components, agile teams plan by functionality. At the beginning of the iteration, small pieces of functionality are selected and planned. For this example, an iteration might include functionality like: the user has to be able to purchase a stock that has already been entered into the system. Clearly, this will require development in all three architectural components of the system. For example, the database component will need to develop the API for a buy transaction (but not the rest of the transactions) and the API to create a stock lot (but not delete it or update its value over time). Similarly, the business logic component needs the error checking on the validity of a buy transaction but not the ability to track its performance over time. The GUI will require the development of a screen to allow the user to input the information about the purchase, but the rest of the application around that screen may be non-existent or mocked up if it hasn't been previously developed. The team may choose to specify and schedule these sub-tasks, but they do not have to. None of these sub-tasks is considered complete until the entire piece of functionality can be verified.^[3]

^[3] Given the specification of this task (which has no output required), the functionality can be shown to be complete by demonstrating that the data gets stored properly in the database by hand, if there is no existing GUI to show that.

There are two critical differences between planning by functionality and planning by component.

First, although individuals may be working on particular parts of the system, the goal is to produce the required functionality, and each engineer knows exactly how his code fits into that functionality. The engineer who is building the logic for the buy transaction in the database will know exactly how that interface will be used by the business logic in response to a particular input from the GUI. Second, no task is complete until the functionality is demonstrated, but because the functionality is relatively small, that will happen during this iteration. This ensures that not only are the individual components coded, but they also work together to make a functional addition to the system.