The COCOMO Suite is used to transform software size into the amount of time and effort that would be required to implement it. When projects were performed using the waterfall approach, once the schedule and effort were established, the planning was fairly automatic. Development was broken into phases, the phases were broken into tasks and the project was executed. That was the theory. In practice, it usually involved some false starts, rework and assignment of blame. The situation is different with agile development.
In agile development, the team has to have three different targets in mind at all times. The first target to consider is the overall completion date. However, useful software never seems to be done. WordPress is still evolving. The same is true of the Microsoft Office suite. Therefore, software should debut as a minimum viable product (MVP). The agile/lean software development revolution has been felt in many areas. One of these is marketing. In marketing, the MVP is the simplest version of a product that can be placed into the hands of a customer. The customer must feel that it is valuable but it may not have all of the features that will eventually be incorporated into the product. In new product development, this gives the company an income stream. More important, the MVP opens up a dialogue where the customers and prospective customers can direct future versions of the product. Customers can choose the features that are the most important to them. It provides a product development direction.
The concept of an MVP is not just for companies developing products for external customers. It applies to in-house developers who are building software for other departments. The sooner that something usable can be placed in the hands of fellow employees, the sooner the business value of that software will be felt by the organization. The same is true for customer feedback. Agile development welcomes change, even when it comes late in development. This is one of the 12 principles of agile development. Once software is in the hands of any users, internal or external, they will see problems and opportunities that were unanticipated when the initial user stories were being drafted.
According to the principles behind the agile manifesto, the agile team should “deliver working software frequently, from a couple of weeks to a couple of months, with a preference to the shorter timescale.” This is a release. In the diagram above, the MVP is delivered in two releases. This is simply an example. The MVP might be done in one release or several. The releases might be require different amounts of time as long as they are each two months or less.
A release results in a working application. Releases have a psychological impact. A release lets the customer know that work is being done. The release sometimes has a business benefit. For example, a release might let customers enter code or business reference data into an application. This data might then be used by future releases. The first release is also important to the agile team. From a psychological point of view, it proves to themselves and their customers that they can work together and accomplish something. There is also a technical component to the first release. It allows the team to debug the tools and techniques that they are using to build their application from the development environment to the production environment.
It is great when the MVP can be delivered in a single release. It is also uncommon. It is critical that MVP not be forced into a single release. If the MVP is so restricted in terms of functionality that is is not truly valuable to a customer, then those prospective customers will be turned off and burned off. There may not be an opportunity to approach them with an improved product. Furthermore, the underpowered MVP may allow competitors to know about the product. They may see some unique idea that they can capitalize on. One of them may have the ability to take that product idea and implement it in a way that satisfies these customers. It is important to realize that everyone has customers and competitors. This is obvious in a product development company. For in-house developers, their customers are the fellow employees that will use the application. In-house developers also have competitors. These include firms that want to sell software that comes close to meeting the needs of organization, software developers who are willing to develop the same software, end-user groups that think they can better meet the requirements of the application. If customers become frustrated, they may turn to one of these alternatives.
Once it is discovered that the MVP requires more than two months to complete, then a new first release must be estimated. The stories and elementary processes that were estimated should be examined. A subset of these can be selected for the release. In some cases, a user story will stay in the release but it will be implemented in a simpler form. This may mean that some of its elementary processes associated with that user story are put on hold. This subset is estimated. It will probably be more or less than the two month target. Based on this, more functionality may have to be removed or it may be decided that some functionality should be reinserted. This process of changing functionality and re-estimating is iterative. It continues until a set of functionality is identified that can be implemented in the timeframe of a release.
The lowest level of planning is the iteration level. When Scrum is being used, these are called sprints. Organizations usually decide on a standard amount of calendar time for their iterations. This can vary between one week and one month. Two week iterations are common. The entire agile team is involved. Therefore, the amount of time and effort are fixed. There is some question regarding how much functionality will be implemented. User stories will be assigned to an iteration. The project owner is responsible for establishing the priority of user stories. The project team usually uses story points and velocity to decide how which stories will be worked on. Even if the selected stories are not completed, the iteration ends at the end of the iteration length. If some stories were not completed, they get added to the backlog of stories to worked on during subsequent releases. If all of the stories are completed, then the backlog is checked for additional stories to work on. The sprint does not complete early.
There are many activities and meetings that occur during each iteration. They are usually specified by the organization and the particular variant of agile that is in use. Stand up meetings each morning are common. Review meetings at the end of the iteration are also common. Obviously, all of these activities need to be done and are automatically included in any iteration planning. Background grooming is one of these activities. While working on an iteration, the team will develop a better understanding of the user stories they are working on as well as some of the stories that are in the Product Background. Based on this new understanding, elementary processes may be added to or deleted from some of these stories. The same is the case for logical files. When this happens, it may impact the estimates that were done for the release or the MVP. If the impact is significant, new estimates of schedule or cost will have to be presented to stakeholders.