Romulus methodology is summarized in the next figure:

Activities:

Plan phase
P.1 – Evaluate previous iteration
Description: Users and developers gather to evaluate the work that has been done in the last iteration
Input: Software of previous iteration
Output: Users' feedback on the application and developers' comments about the development phase
Roles: Users and developers
Validation: Users and developers have finished giving their views of the software
Best practices: - Let users interact with the system directly
                - Guide users to the application but try to let them use it freely
                - Using cards to pick user's feedback is a way to allow users to freely put any comment for developers' work improvement
Tool support: Infrastructure for demoing an application. Virtualization software might help in some scenarios

P.2 – Project planning
Description: Users and developers gather to elicit project requirements and define milestones and objectives
Input: Previous project plan (stories and release definitions), if it exists
Output: Project plan
Roles: Users and developers
Validation: P.2.1 – Story writing and P.2.2 – Release definition have been performed
Best practices: - Effective customer relation lies in both developers and users feel part of the same team. Introduce the expected development team and be neutral
                - Discussions should be much more about software functionalities rather than contracts
                - Developers should focus on users' needs rather than on the possible difficulties to fulfill them
Tool support: Cards, blackboard, project management tools and collaborative tools such as wikis or shared spreadsheets

P.2.1 – Story writing
Description: Users write stories that define what they expect from the software system. Developers help in the task of detailing the stories
Input: Previous set of stories, if it exists
Output: Set of stories
Roles: Users and developers
Validation: Users have finished thinking of stories for the application
Best practices: - Developers should think if users' stories can be interpreted in many ways in order to help users to express themselves better
                - Developers' estimation of efforts should be independent of their order of execution to allow users to freely define which stories to be included in each release
Tool support: Blackboard, cards or any software to take down users' stories

P.2.2 – Release definition
Description: Users, helped by developers, define the stories/features that will be included in each release
Input: Previous release definitions, it they exist
Output: Release definitions
Roles: Users and developers
Validation: Users have finished stating which stories they want to be included in each release
Best practices: - Developers should recommend which stories should be implemented first in order to be able to have a basic system working
                - Users can freely decide which stories include in each release
Tool support: Blackboard, cards or any software to take down release definitions

P.3 – Iteration planning
Description: Developers plan iterations to match releases' dates
Input: Previous iteration definition, if it exists
Output: Iteration definition (set of tasks and their assignation and scheduling)
Roles: Developers
Validation: Tasks cover all the stories
Best practices: - Tasks should be well defined and as simple as possible
                - A way of defining tasks can consist of making incremental partitions of stories or bigger tasks. Partition criteria can be, for example, aspects covered, level of detail, integration with modules, etc.
                - Excessive work load on developers only lead to delays
Tool support: Project management tools and collaborative tools such as wikis or shared spreadsheets

Design phase
D.1 – Initial design
Description: An initial software design of a task to develop  is outlined
Input: Task to develop
Output: Initial domain model
Roles: Developers
Validation: The model covers all the concerns of the task
Best practices: - Domain concepts can be identified by selecting nouns in the domain's vocabulary and removing synonyms
                - The initial model should be as simple as possible
Tool support: UML tools (ArgoUML, UML2 Tools, ...) or text editors

D.2 – Design refactoring
Description: The design of the model is refactored
Input: Initial domain model
Output: Domain model
Roles: Developers
Validation: The model covers all the concerns of the task
Best practices: - Analyse associations, aggregations, entities, value objects and services
                - Validate the model and use factories to create objects
                - Divide the model into various modules
Tool support: UML tools (ArgoUML, UML2 Tools, ...) or text editors

Implement phase
I.1 – Interface definition
Description: Interfaces or empty classes are defined for a specific task under development
Input: Domain model and task to develop
Output: Interfaces or abstract classes
Roles: Developers
Validation: All domain objects have a corresponding interface or class
Best practices: - Interfaces and classes correspond to entities and value objects in the domain model
                - Build interfaces by defining responsibilities and collaborations among classes
                - Update the domain model in case that it changes
Tool support: Romulus and IDE or code editor

I.2 – Test definition
Description: Test cases are defined for a specific class and task
Input: Class interface and task to develop
Output: Test suite
Roles: Developers
Validation: Test suite covers a reasonable number of test cases
Best practices: - Automatically generated tests should have been generated
                - Semi-automatically generated tests should have been filled with values to be executed
                - Think of manual test cases as those code interpretations the computer cannot infer from the code.
                - When writing manual test cases, think from the user side, maybe by rereading story cards before writing tests.
Tool support: Romulus test generator and IDE or code editor

I.3 – Interface implementation
Description: Classes are implemented
Input: Class interface and task to develop
Output: Class implementation
Roles: Developers
Validation: Test suite outputs no errors
Best practices: - Pair programming
                - Code should be as simple as possible
                - See Roma handbook [Aqu08] for implementation details
Tool support: Romulus and IDE or code editor

I.4 – Refactorization
Description: Classes' implementation are improved
Input: Class implementation
Output: Executable and tested code
Roles: Developers
Validation: Test suite outputs no errors
Best practices: - Unnecessary complexity should be removed immediately
                - Try to avoid repetition by grouping methods or using inheritance properties
                - Code should be understandable and as simple as possible
                - Tool support
Romulus and IDE or code editor