The first Phase of our engagement is to create an accurate set of requirements. The requirements are often broken down into Releases
and Iterations. A release is a large unit that is typically what is released
to your users. Iterations are smaller building blocks used for larger payment and review milestones. Inside of each iteration will be one or more sprints. Sprints can last a week or two and are used as checkpoints to ensure that the original requirements still hold true and to get feedback quickly to avoid costly miscommunication. Sprints will be defined as we progress through the iteration.
During design we accomplish two goals. The primary goal is to test our expectations and make sure our concept of the product matches yours. Depending on the project scope we do this by either creating a basic layout template, or we create a full set of wireframes showing each major part of the system. The secondary goal is to ensure that the visual components match with technological limitations of the platforms involved. This architectural design directly feeds into how we develop user stories and plan for future development. During this phase we will also do a quick risk assessment and create any necessary design documentation and prototypes to ensure development will go smoothly. This is usually only necessary for systems with cutting edge or uncertain technology requirements.
3. Development / Testing
We utilize Test Driven Development as well as an Internal Quality Assurance process to ensure that prior to being sent to a client for review each task is checked by automated testing and your Project Manager and/or a QA Engineer. This double assessment helps to increase the speed of development and your review. During development your Project Manager, Architect and Development team communicate daily to make sure the project is on task and being completed to the highest quality level possible.
At the end of a sprint we showcase the completed tasks. We also deliver a sprint report which identifies what was actually completed during the sprint. At this time, we will deliver the next sprint plan for review so that you are informed what will be starting the next day and can add feedback or input as needed.
At the end of an Iteration and/or a Version we do a Retrospective. This is where we receive feedback on the current Iteration and/or Version as well as how the process overall is working for you. Feedback on our work product as well as feedback on the process as a whole is critical to ensuring we are providing the best service possible.