Coria's Iterative Project Approach (Agile)

May 10, 2017 / Anne Saulnier

 

Agile projects are akin to running as far as you can in 60 minutes. You have a set starting point and a goal, but your exact path may change throughout the project, depending on what obstacles or opportunities you find along the way.

Our take on agile is the Coria Iterative Project Approach (IPA). This methodology fits within the agile framework and is based on Scrum project management principles. It focuses on delivering the functionality that will provide the most business value first, while continually refining goals throughout the project based on what the team learns along the way. This style of project is ideal if you need to quickly deliver value to your end users and adapt to potentially changing requirements or market conditions.

The Coria Iterative Project Structure is comprised of the following phases:

 

 

 

Discover

At the beginning of the project, we will work directly with you and your team to develop a shared understanding of your business objectives and the vision for the project. This is typically accomplished using requirements gathering workshops and interviews with key stakeholders and business users.

The key output of this phase is the Product Backlog, which is a set of all the identified requirements written from the users’ perspective as user stories. This focuses the project team’s attention on who the feature is for and why it is important. The Product Backlog is a living, breathing list of requirements that can be re-prioritized and modified at any time during the project.

During the Discover phase, we will also decide as a group how long each working cycle (or sprint) will be. Typically we recommend two-week iterations but can accommodate anytime box shorter than thirty days.

 

Plan

At the beginning of each sprint, we will hold a Sprint Planning Session for the entire project team. This is a single meeting where we discuss the highest priority stories in the backlog, specify the user stories in detail, and provide the development team with enough information so they can outline the individual tasks for each user story, and estimate the level of effort required to complete each task.

Instead of estimating each backlog item in hours, we use a relative, points-based system. After the first sprint is complete, we are then able to project how many points can be achieved in a single sprint based on the past performance of our team.

After the initial estimating is complete, the development team breaks each backlog item out into the tasks that will be required to complete the work. Tasks are the only items in agile that are measured in hours. Ideally, each individual task should be small enough to take no more than eight hours to complete.

 

Build

Each day of the sprint will begin with a Daily Stand Up, which is a 15 minute-meeting where each team member covers what they accomplished since the last meeting, what they plan to do next to move the project forward, and what obstacles are blocking their way.

Throughout the Build phase, all backlog items that the team commits to will be designed, developed, tested, reviewed, and optimized by the team so they will be ready to launch at the end of the sprint. Daily communication with the Product Owner and business users is encouraged so that constant feedback can be incorporated into the design.

 

Review

At the end of each sprint, we will hold a Sprint Demo, which is open to all project stakeholders. In this meeting, we run through each user story tackled during the active sprint and demonstrate how it has been implemented. The Product Owner will then decide whether to accept the implementation based on the acceptance criteria. If accepted, the user story is considered complete.

We will also hold a Sprint Retrospective where all project team members are invited to discuss what went well, what could have gone better, and what specific actions we can take to improve the process before beginning the next sprint.

 

Ship

At the end of the Sprint Demo, any tasks that are considered complete can be deployed to the end user. This means that working software that provides real business value will be available for release in as little as two weeks. 


Head Office Hours

Global Support Hours