Agile is a software development methodology in which the process of development occurs through short increments. The phases of development occur continuously in iterative cycles involving creating requirements, design and implementation, testing and reporting. After each iteration, the team members meet to discuss the past iteration and the next phase of the project. The product owner, customers and the development team create requirements for the end product through the use of user stories. User stories are short descriptions of application functionality from the perspective of the user. A collection of user requirements are stored in the product backlog, to be developed as the project continues. The product owner or the business analyst determines which requirements from the product backlog the team will work on during each iteration. Those stories are then moved to the Sprint Backlog, to be used for that sprint. 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." In traditional development methodologies, a requirements document is usually developed first and lists all requirements the team will work 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.
The user stories are very simple so that designers can develop portions of the project in short iterations. During the meetings, before an iteration begins, the team can discuss in more detail the specifications of the story and expand on the original idea. The team does not need to develop every user story presented, but they are a starting point of understanding what the customer needs.
Once user stories are written, the team, including the product owner, assigns a priority and approximate develop time. If one story will take more time than a single iteration, it can be broken down into multiple requirements. As with all agile projects, if the team decides later on that a requirement is not needed, it does not have to be turned into functionality in the system. Also, the team can write new requirements as they become apparent.
There are many benefits to using user stories over a more traditional requirements document, including:
1. User stories are easy and fast to write. Not a lot of time or money is invested in writing them; therefore, if they are changed or never used, the team has not lost a lot in developing them.
2. User stories are ideally written by the "user" and therefore allow the product owner and development team to spend time with the user and better understand the functionality that they want; not just at the beginning of the project, but throughout. Also, the development team and product owner can write them and they are forced to but themselves in the customer's position, enabling a better understanding of what the end product needs to accomplish.
3. The user stories are simple enough that an outsourced team would easily be able to understand the end functionality. Even with language barriers and miscommunications, an outsourced development team can still understand the basic functionality the system requires.
4. The user story allows for the development team to be creative in designing the product. It gives a very basic outline of a needed functionality of the system but does not force the development team into specifics that may not work with all parts of the system.
The user story is a very useful tool in agile software development. It is a starting point for discussing requirements; however, they can cause disagreements among team members about how to fill in the gaps of the story. It is important to have a product owner, customer or business analyst to clarify and resolve specific issues that may arise with the ambiguous nature of the stories.
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." In traditional development methodologies, a requirements document is usually developed first and lists all requirements the team will work 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.
The user stories are very simple so that designers can develop portions of the project in short iterations. During the meetings, before an iteration begins, the team can discuss in more detail the specifications of the story and expand on the original idea. The team does not need to develop every user story presented, but they are a starting point of understanding what the customer needs.
Once user stories are written, the team, including the product owner, assigns a priority and approximate develop time. If one story will take more time than a single iteration, it can be broken down into multiple requirements. As with all agile projects, if the team decides later on that a requirement is not needed, it does not have to be turned into functionality in the system. Also, the team can write new requirements as they become apparent.
There are many benefits to using user stories over a more traditional requirements document, including:
1. User stories are easy and fast to write. Not a lot of time or money is invested in writing them; therefore, if they are changed or never used, the team has not lost a lot in developing them.
2. User stories are ideally written by the "user" and therefore allow the product owner and development team to spend time with the user and better understand the functionality that they want; not just at the beginning of the project, but throughout. Also, the development team and product owner can write them and they are forced to but themselves in the customer's position, enabling a better understanding of what the end product needs to accomplish.
3. The user stories are simple enough that an outsourced team would easily be able to understand the end functionality. Even with language barriers and miscommunications, an outsourced development team can still understand the basic functionality the system requires.
4. The user story allows for the development team to be creative in designing the product. It gives a very basic outline of a needed functionality of the system but does not force the development team into specifics that may not work with all parts of the system.
The user story is a very useful tool in agile software development. It is a starting point for discussing requirements; however, they can cause disagreements among team members about how to fill in the gaps of the story. It is important to have a product owner, customer or business analyst to clarify and resolve specific issues that may arise with the ambiguous nature of the stories.
Overall though, user stories offer a fast and efficient way to develop requirements in agile software development methodology.
No comments:
Post a Comment