The plan phase is inspired in Extreme Programming's planning structure. The plan phase for the Romulus methodology consists of a Planning Meeting in which project and iteration objectives and tasks are discussed. All team members, including the user, need to be present in the meeting. As the plan phase is present in every iteration, the Planning Meeting will be held weekly. The duration of the meeting will be longer in the first iteration(s) (various days if necessary), where user requirements will likely be more incomplete and unstable.

The Planning Meeting consists of the activities shown in the figure.

P.1 – Previous iteration evaluation (except in the first iteration). Development progress, risks, problems, as well as changes in environmental variables, such as resources or technologies, will be presented by team members. They will be considered to appropriately plan further iterations.
P.2 – Project planning. In this part, long-term goals will be defined (first iteration) or updated. Software requirements and timing of both partial and final releases will be specified. It includes tasks P.2.1 – Story writing and P2.2 – Release definition.
P.3 – Iteration planning. Finally, a planning for next iterations will be defined (first iteration) or updated.

P.1 – Previous iteration evaluation
An evaluation of the previous iteration is performed in this activity. This consists of:
  1. Show application to the users. Functionality of the currently developed application is shown to users. Users might find unexpected functionality in the application as long as their view is different from that of developers. Similarly, the users might find interesting other aspects of the application that they did not expect.
  2. Users' feedback. Get users' feedback on their contact with the application's current version.
  3. Developers' feedback. Get developers' feedback on their development experience in the previous iteration. Problems, risks and changes in environmental variables will be identified.

P.2 – Project planning
Project goals are presented by the users. Usually, users will present their desires and problems using a non-technical point of view. It is the responsibility of developers to extract and elicit requirements out of users stories. Developers' technical background might influence users statement of stories, so it is important that developers let users freely express their desires and problems.
Thus, the following structure is proposed for the first project planning:

P.2.1 – Story writing: Stories are written by the users. In stories, users state what they want the system to do. This involves five parts for each story:

  1. Write a story. Developers do not take part.

  2. Story splitting. Most times, stories will be too complex to estimate risk and time to develop. In this case, they should be split appropriately by developers. A way of splitting stories can consist of making incremental partitions. Partition criteria can consider, for example, areas covered, roles involved or non-functional requirements covered. It is advisable that stories that are related to soft goals do not extend more than one non-functional requirements. A classification of non-functional requirements in web applications can be the following:
    - Scalability and load: describes how the application should scale to requests and the performance that it should fulfill.
    - Security: describes what authorization, authentication, accounting and vulnerability requirements must fulfill the application.
    - Semantic and mashup capabilities: describes how other applications and services would be aggregated and how the current application would be open through the use of semantic technologies.
    - Integration: describes what other systems or modules the application needs to be compatible with.
    - Presentation: describes the requirements for web user interaction.
    - Persistence: describes the way resources need to be persistent along time and which resources should be persistent.
    - Maintainability: describes what an application has to fulfill in order to be maintained.
    - Internationalization: describes how an application is adapted to different languages and localizations.
  3. Estimate value. Users arrange stories into three value groups: critical, significant business value and nice to have.
  4. Estimate risk. Developers arrange stories into three risk groups: low, medium and high risk. A possible approach considers three risk indexes. All indexes are added, assigning the user stories a risk index of low (0–1), medium (2–4), or high (5–6):
    1. Completeness (do we know all of the story details?): complete (0), incomplete (1), unknown (2).
    2. Volatility (is it likely to change?): low (0), medium (1), high (2).
    3. Complexity (how hard is it to build?): simple (0), standard (1), complex (2).
    4. Estimate time. Developers estimate how much time the piece of software implied by a story will take to develop.

P.2.2 – Release definition: The user decides which stories will be implemented in each release. Developers' advice should be considered in order to favour a logical order (from a technical point of view) of implementation of stories. Based on the user stories, release dates are determined.
In next iterations, project planning will require updates, so the next structure is proposed:

P.2.1 – Story writing:  Update stories. As a result of the users contact with the application's current version, stories might be rewritten or even new stories might be written. The same procedure as in the first project planning will be followed:
  1. Write/rewrite a story.
  2. Story splitting.
  3. Estimate value.
  4. Estimate risk.
  5. Estimate time.

P.2.2 – Release definition: Update release definition. Current release date will be updated according to stories new time estimations. The user might be interested in redefining the release by picking other stories.

P.3 – Iteration planning
Iterations are planned in order to meet release date. Users do not need to be present in this part of the Planning meeting. This activity consists of:
  1. Translate stories into tasks. Stories are split, if needed, into tasks that fit one development iteration time. Tasks can also be combined if they are too short to fit one iteration time. A way of defining tasks can consist of making incremental partitions of stories or big tasks, where partition criteria can be, for example, aspects covered, level of detail, integration with modules, etc.
  2. Set load factor. Each developer sets the amount of hands-on development time within one iteration depending on time required for meetings or other projects.
  3. Balancing. Tasks are balanced out among the programmers considering load factors. If a programmer is overcommitted, other programmers must take over some of his or her tasks and vice versa.