About us > Our work methodology

Our Work Methodology

Most of the projects start with a meeting with the client. In that meeting we try to understand the project and define an initial draft of a Project Vision.

With that information we prepare an initial contract and proposal. That proposal usually includes the high level requirements identified from the Project Vision.

Once the contract is signed, we start defining the requirements with the customer. Requirements are put together in a Software Requirements Definition document. Sometimes the requirements defined during this stage result in the need to adjust our time estimates and quote.

During this stage we also recruit the all the necessary resources for the project, we begin with the architecture design and we setup the working environment for the development process.

Next, we move on with the development of the software. We use a methodology called Scrum for our software development process. Scrum is an agile development methodology based in the following principles:

• The customer or Product Owner has an important involvement in the development process.
• Product requirements are defined with the Product Owner (usually as User Stories) and put together as Product Backlog Items. It is a desired practice that Product Owner actually writes requirements.
• Product Owner prioritizes the Product Backlog Items in accordance with its business value.
• Product Backlog Items are estimated, whether by time or relative weight, only by the development team. This estimation is adjusted constantly, usually at the start of each Sprint.
• The development cycle is divided into time-boxed Sprints of a fixed duration (typically 2 to 4 weeks). Each Sprint has a clear Sprint Goal and produces a working product increment.
• Before each Sprint starts, a Sprint Planning meeting is done to choose which requirements are implemented and the details on each are discussed. The whole development team and Product Owner participate.
• The requirements that are implemented in a Sprint constitutes the Sprint Backlog.
• Once a Sprint starts, no changes are accepted for the Sprint (bugs could be an exception). In any change or new feature is identified, it is added to the Product Backlog.
• A Daily Scrum meeting is held every morning only between members of the dev team. This is a short-stand-up meeting where each member communicates: what he did yesterday, what he will be doing today and any impediment he is facing.
• At the end of each Sprint a Sprint Review or demo is held where the team demonstrates the product increment to the Product Owner and any other involved stakeholder.
• At the end of each Sprint, a Sprint Retrospective is held to discuss what it is working and what it is not.

Once the last planned Sprint ends we usually allocate a time-box equivalent to one Sprint for corrections and any necessary documentation that the client needs.

The following graphic represents our work methodology:

Each Sprint starts with a Sprint Planning and ends with a Demo and a Sprint Retrospective. Usually we allocate 25% of the development time for corrections that are needed in previous versions of the software. A Daily Scrum meeting is also held between development team members.

The following graphic illustrates a single Sprint:

Definitions:

• SRS stands for Software Requirements Specification.
• SBL stands for Sprint Backlog

Scrum Resources

• Scrum Video: http://www.youtube.com/watch?v=Q5k7a9YEoUI
• Scrum Presentation: http://www.mountaingoatsoftware.com/scrum-a-presentation