Our Methodology

Defined as User Stories, which describe user goals and tasks. Do not reflect technical details. Specified in the format “As a {User Type}, I should be able to {Task}, so that {Reason for Feature}”. Requirements are prioritized, with the most important User Stories being developed first. A product backlog is created, which is a list of all open User Stories.

Defines and documents requirements thoroughly, up-front, before any development begins. All features/functionality must be fully anticipated by the client and documented by the development team for a truly successful project.

The project timeline is comprised of iterations, typically lasting 2-4 weeks. At the start of each iteration, the development team and the client collaborate to decide which features will be delivered at the end of the iteration, and the development team commits to delivery of this feature set. At the end of the iteration, the client receives a complete, functional release with the aforementioned features.

Project timelines are planned as a series of stages, each dependant on the completion of the last. The entire project timeline is planned from the start, leaving little to no flexibility in requirements. A releasable product is delivered at the end of the project timeline.

A team is assigned to the project. The entire team takes responsibility for delivery of the project. There is no team hierarchy – each team member is equally responsible for delivery of the project. Emphasis is placed on team collaboration, meaning no one person should be working on any project feature without discussions with the team.

Emphasis is placed on individuals delivering their piece of the project. A hierarchal structure means less collaboration. Failure of one team member to meet their deadlines can cause delays in the overall project plan.

Changes are welcomed during all stages of the project. New User Stores may be added to the product backlog at any given time. The development team will assess the timeframe for implementing the changes, and the client has the option to either replace existing backlog items of similar scope at no additional cost, or add these as new items, which will incur cost.

Contractual agreements oftentimes hinder the ability to make changes to project scope during development. Changes typically cost more due to the formal requirements documentation needing to be revised for the new functionality. Timelines can be significantly impacted.