From my perspective, the number one key difference between Waterfall and Agile is the ability to respond to the evolving business needs immediately. This is the big deal. This is why so many companies are adopting Agile.
Let us first define an Agile in a way that we can understand it properly. Agile is a software development methodology in which the process of development occurs through short increments. The requirements and solutions evolve through collaboration between self-organizing cross-functional teams
Therefore, to adopt agile approach at your workplace, your team needs to practice and make a strong commitment to change. Becoming a professional agile team means re-engineering the way they think about work. Agility is a mindset that can be improved and not perfected.
I will give an example; I have an online shopping issue. I have decided to buy the latest computer items everything online which include (ATX tower, Power Supply, CPU, video card). I mean everything, even the monitor. It's fast, easy, inexpensive, and convenient, so what's the problem? Well, the problem is assembly. I'm not very hardware guy inclined. I can muddle my way through, but the bigger problem is that I don't have all the tools. Without the right tools and skills, it's harder to successfully assemble my purchases. In the same way, your agile project needs the right tools and the right skills to succeed.
To fulfill these needs and skills, you'll need the following full-time roles: Scrum Master, Product Owner, Developer, Business Analyst, or BA, Quality Assurance Analyst, or QA, a Database Analyst, or DBA, and Subject Matter Experts, or SMEs. These team members can be loosely divided into two units, the Customer Unit and the Development Unit. While they serve separate purposes, they are one team.
The Scrum Master role is much more practical. He will spend most of his time removing obstacles for the team and ensuring they have a great work environment. The product owner should have a direct line of communication with the customer. He works closely with the final users of the product and determine the work for the rest of the team. The product owner works with the development team to create the requirements for the end product through the use of “user stories”
This is phrase looks weird, but frankly speaking it is amazing! User stories are short descriptions of application functionality from the perspective of the user. They are small and are generally written in the same format. I usually say, user stories like Lego Game, developers will create an awesome model and write a convincing project description to build the Legends of Chima!
Well, the first segment of the Story tells the team who will be using it. This is important because if you're not focused on the right User, you won't provide the right product. The second part of the Story is very simply what needs to be built. So all these collection of user requirements will be stored in the product backlog, to be developed as the project continues.
The backlog is a ranked list of all the functions and features that the customer would like to see in the final product.
The user stories follow the general pattern of:
I, role, want to be able to, functionality, so I can, reason.An example would be, "I, as a student, want to be able to pay tuition online so I can register for classes." Or “As a Database Administrator, I should be able to revert a selected number of database updates so that the desired version of the database is restored. “ In traditional development methodologies, a requirements document is usually developed first and lists all requirements that team will be working on until the project is complete.
In Agile development, there is no large requirements document because the specifications of the project can change easily as the technology changes or new ideas are presented.
They are easy way of taking care of customer requirements without the need to make formal requirement document and without the need to perform tasks which are about administering and maintaining them
There are many benefits to using user stories over a more traditional requirements document, including:
Simplicity
User stories are simple and fast to write, both the customer and the team can describe the exact requirements (Functional and Non-Functional) without using, multiple long descriptions of the task that they want to achieve.This simplicity will contribute to the process because the customer does not need to know the technical aspects of his requirements, the simplicity in writing user stories will help him to use a basic language to reflect his functional needs.
Written by the customer
User stories based on the customer requirements that knows what he wants to get at the end of each iteration. This allows the scrum team to communicate directly with the customer (or with the product owner that represent him) to get a better understanding of the real needs and what they should deliver.Easy to Prioritize
Once the user stories added to the product backlog, the product owner with the team has the opportunity to understand which stories are more important to the customer. Following this basic approach, the PO and the team can prioritize the important user stories first; this prioritization will guarantee that the team will deliver the most important user stories first which will lead to happy customers. This will also help drive understanding with clear and concise explanations of the problems a user faces.Communication
User stories are a great way to increase the communication among the team members, and between the team and the product owner, a good user story will enable the relevant stakeholders to make a real conversation about the requirements and expectations of the customer.Collaboration
The team will review each story during the sprint "Planning" meeting, this will increase the discussion between the team members (Especially when the need to make the requirements analysis) so they will increase the knowledge prior to implementation.All in one
Each user story contains all the relevant information that the team members need to start the implementation (Acceptance criteria, Requirement specification and done criteria) without searching different parts of the data between multiple resources.Commitment
User stories will allow the team to evaluate each story so they can determine the work effort prior to taking any commitment during a sprint.Your future planning efforts will bring the team to near-term, committed deliverables. User stories is a stage that assure your stakeholders they will get committed plans from the team
Thank you!
