Iterative development was created as a response to inefficiencies and problems found in the waterfall model. Modified Waterfall, Rational Unified Process (RUP) and most, if not all, agile models are based on iterations.
General idea is to develop a system through iterations (repeated cycles) and incrementally (in small portions of time). Through them team members or stakeholders can learn from their mistakes and apply that knowledge on the next iteration. Continue reading →
“User stories are a promise for a conversation” (Ron Jeffries)
A BDD story consists of a narrative and one or more scenarios. A narrative is a short, simple description of a feature told from the perspective of a person or role that requires the new functionality. The intention of the narrative is NOT to provide a complete description of what is to be developed but to provide a basis for communication between all interested parties (business, analysts, developers, testers, etc.) The narrative shifts the focus from writing features to discussing them.
Even though it is usually very short, it tries to answer three basic questions that are often overlooked in traditional requirements. What is the benefit or value that should be produced (In order to)? Who needs it (As a)? And what is a feature or goal (I want to)? With those questions answered, the team can start defining the best solution in collaboration with the stakeholders. The narrative is further defined through scenarios that provide a definition of done, and acceptance criteria that confirm that narrative that was developed fulfills expectations.