Agile Development Process

Although every team has their flavor of following and implementing the Agile software development process, there are specific guidelines which have been refined based on the industry feedback. These guidelines are outlined below.

Vision: Every project starts with a vision. The stakeholder defines his/her vision in a few sentences. This may be a very high level of 60,000 feet view of the project.

I would like to develop a mobile banking platform

Project Planning: Once the vision is defined then its time to get together with stakeholders, project managers, engineers, etc and come up with high level 30,000 feet view of the project by defining features called EPICS. High-level EPICs are determined to capture the feature set required for accomplishing the overall vision.

EPIC-1: Customers can send money to other members instantly using their phone numbers.

Milestone Planning: Following the high-level EPICS identification there is a need to define project milestones, which will also help in release planning. EPICs are assigned to different milestones based on their priorities.

Milestone 1.0 will include EPIC-1, EPIC-2, EPIC3.

Milestone 2.0 will include EPIC-4, EPIC-5.

Sprint Planning: Once the features are defined and prioritized, engineers commit to them during the sprint planning sessions. In these sessions, engineers get together with the product owners and sometimes stakeholders to dive deep into the high priority features. During the process, the acceptance criteria for the feature is defined.

GIVEN the member has a bank account

WHEN the member sends money to another registered member

AND the transaction is successful

THEN the receiver will receive money in his account

AND the money should be spendable by the receiver

AND the receiver will get the notification of receiving the money

Story Estimation:After the top priority stories are defined and the requirements are clear, the engineering team votes on the estimates. This helps determine the effort level required to implement the story. Every team has their style of estimation. Some follow the Fibonacci series, and some follow the number of days, etc. If the estimate is too big, the story needs to be broken down into smaller more manageable stories. The story should be short enough to be finished within a few days.

Iteration Start: After estimation, the stories are moved into the iteration, and the engineering team commits to them and starts working. Iterations are usually between 1–4 weeks, but majority teams follow two-week iterations. Iterations represent the heartbeat of the project. At the end of the iterations, there should be some demo-able product.

Daily Stand Ups: Everyday engineering team would meet with their product owners and give updates. These updates are normally focused on three things

What did I do yesterday?

What do I plan on doing today?

Am I blocked by something?

QA: The software qualifies as good quality if its easier to maintain in the long run. It is essential for the success of the project. But merely good quality is not enough, it is also crucial to make sure the software is built as per acceptance criteria, can handle various error scenarios and meets the performance criteria. All these are verified and tested during the QA phase. Once the engineer feels comfortable with the implementation the story is assigned to the QA team for further grilling.

Demo: At the end of the iterations, there should be some demo-able product. During the demo meeting, engineers demo the finished stories to the product owner and/or to stakeholders. If the demo meets the acceptance criteria defined in the story, the story is accepted and considered complete otherwise it goes back to in progress.

Retrospectives: A retrospective meeting usually follows a demo meeting. During retrospective, the team reviews their performance and deficiencies. They focus on what helped them this iteration and what was lacking that can be improved in the next iteration. Once the team identifies problem areas, they brainstorm for a solution. They pick a solution to try out in the next iteration, and that’s how they engage in a continuous improvement cycle. Retrospectives are also the time for the team members to appreciate or encourage each other.

Release: At some point during the project development if a milestone is achieved then a release may be necessary to get the project out in the hands of the customers and get early feedback.

Feedback: After the software is released, feedback is collected, and more stories or epics may be added to either improve an existing feature or add a new feature.