def’n 1: managing expectations
The common use of the term ‘managing expectations’ refers to aligning unrealistic hopes/beliefs with reality.
Despite its overall level of maturity, the agile community continues to confuse agile requirements with testing and/or user stories. These types of misconceptions have spurred me to write this blook. Over many years I have consistently written articles, presented at conferences, and taught courses on the topic of Agile Requirements. Some highly esteemed peers within the agile community still associate my work with user stories or testing, leaving me feeling completely misunderstood.
Misconception 1: Agile is the same old thing wrapped in new buzz words. Regardless of the brand name, a successful Agile project is easily recognized by its outcomes: delivering valuable, running, tested features on a regular basis. Within this blook I will elaborate on each word of this definition as well as the synergy of the whole.
Misconception 2: Agile Requirements = user stories. User stories are fundamentally a part of the planning process, and are merely a ‘ticket’ into the requirements process (“a promise for a conversation”).
Misconception 3: Agile Requirements = testing. Agile requirements aim to be highly trustworthy specifications. This is accomplished by elaborating the business requirements with concrete examples, and by making these examples executable to have an objective and obvious indicator when the specification and the system are out of synch. Because they are automated, and because they are part of a practice called ‘test driven development’, most people confuse this activity with ‘testing’.
This blook aims to have a broad reach within the community with the aim of addressing these misconceptions and guiding the community to a clearer understanding of the differences and synergies between user stories, agile requirements, and agile testing.