Agile software development methodologies are built to account for change. As such, it is not necessary that the customer creates a detailed list of requirements before the start of the project or that the developers perfectly predict how long each requirement will take to implement. Agile solves the problem by helping us make decisions based on the information we currently have. We create user stories for features that we can currently define and epic stories for feature sets that we need later but are not yet able to define in detail.
A user story is a short description of a required feature written from the point of view of the person who needs it. A story typically follows the form of, “As a TYPE OF USER, I want SOME GOAL so that SOME REASON”. One benefit of phrasing requirements this way is that doing so provides valuable context that helps the development team make fewer assumptions. In other words, to minimize assumptions on all sides, the stakeholders requesting the software must communicate directly with the team who builds it.
User stories also include meta-information pertaining to the feature they request. This meta-information might include a record of conversations between the development team and the product owner that captures details overlooked when forming the initial story. In addition, a list of acceptance tests approved by the product owner accompanies each user story and the development team later uses these predefined acceptance tests to prove that they correctly implemented the story.
When defining an Agile project, we start by creating a list of epic stories. An epic story is a high-level grouping of related user stories and each epic presents a broad requirement for the system without going into detail. As an example, an epic story could be, “As a hematologist I want to visually inspect blood samples so that I can accurately count the number of white blood cells in my sample.” This epic will later be expounded upon and broken up into several smaller stories, some of which might be new epic stories unto themselves.
Defining specifications as user and epic stories helps us manage software challenges in stride. The process demands flexibility, clarity, and communication from the all parties and elegantly avoids many of the common development pitfalls, even without a specification crystal ball.
If you would like to read parts 1, 2, 4, and 5 of the Agile in Action 5 part series, please visit the following pages:
The Ceremonies (Part 1 of 5)
The Scrum Team (Part 2 of 5)
Sprint Planning (Part 4 of 5)
After the Sprint (Part 5 of 5)
If you would like to learn more about Bloomy's LabVIEW consulting services please Contact Us via webform or telephone.
- Jon McBee's blog
- Log in or register to post comments