The Best Guide To Agile Requirements Gathering
#agiledevelopment #agile #agilemanagement
In this session we are going to cover agile requirements gathering, their importance in developing quality software, and how you as a QA engineer can make an impact.
📌 Follow the Agile journey for Success
Our XBOTalk 7 part series we will address AGILE and the Key Solutions to the most common Software Development Pain Points related to Software Quality. By the end of this 7-part series you’ll understand:
✅ Agile Requirements Gathering
✅ Agile Sizing (Epic / Story / Task)
✅ Testing Manual vs. Automation
• What makes a good candidate for automation?
✅ Test Asset Management (highlighting Jira Plug In)
• Storage
• Organization in to groups
✅ Automation Script writing
✅ What is a quality gate, and how to use
✅ KPI
📌 The art of defining clear agile requirements.
First, let’s discuss the problem in that there are many challenges of converting a business concept to a viable software product. This can only occur through defining clear requirements. One of the most common pain points voiced within the software community is the frustration caused by requirements which are not fully defined, or are modified as the development process progresses.
👉 Agile requirements gathering
An Agile requirement gathering starts vague and is refined and becomes more as it progresses from concept, to Epic, to Story, to Task. One of the weaknesses of Waterfall is that the majority of the work to refine the requirements is done during the design stage, and adjustments needed later in the cycle are expensive and create development delays. Our discussion will focus on the Agile process of refining requirements through iterations.
Quality needs to be built into the requirement development process from conception through delivery. One of the key considerations when constructing a requirement is how it will be tested. If the requirement covers new functionality for an existing application, dependencies need to be identified to be placed in testing tasks.
📌 Key to solid agile requirements gathering
The key to solid requirements is asking for the correct level of detail. Once the initial requirements are specified, the team needs to evaluate them for completeness, identify dependencies, and a delivery order. Most organizations want to deliver a minimum viable product first, which means prioritizing delivery according to user wants and needs. A strong requirement has clear acceptance criteria. Acceptance criteria is used to build test cases. And both need to answer at least one of the Why, What, When, How questions:
• Why
Why are we working on this project?
• What
What do we hope to accomplish by completing this project (sprint / build)?
What do we need to accomplish the project (sprint / build) in terms of resources, software, or hardware?
What are the dependencies?
What are the risks?
What is the logical order for the requirements?
• When
When does the project (sprint / build) need to be delivered?
When will the resources be available?
• How
How will the project (sprint / build) be approached in terms of Epics, Stories, and Tasks?
👉 Agile requirements from a Software testing point of view
From a software testing point of view, testing in Agile needs to start early in the requirements phase, by determining if the requirements are testable. QA engineers typically review requirements examining for clarity and completeness, and also give feedback to product managers for requirements that don’t meet these criteria. With clear, complete, and accurate requirements, QA engineers are then able to test criteria for pass/fail that help developers understand the “Definition of Done” for the requirement.
The problem is that in order to do review and provide feedback on requirements requires more than just button pushing of an existing system. Rather, QA engineers have to think from an end-user point of view on what would be acceptable to the user in executing or using the particular function being developed. This requires thinking outside the normal ‘tester’ box, along with domain knowledge of the application.
☞ Software accounting as an illustration
If, for example, the ‘house’ is an accounting software package, and the feature or epic being developed is account reconciliation or general ledger entry to accounts payable, then the QA engineer has to understand how an accountant thinks in order to know if the requirement is clear and complete.
📌 XBOSOFT manages it all
In the next XBOTalk episode we will explore Agile Sizing where you’ll learn how to identify Agile Epics, Stories, Tasks, and Spikes, using an Agile Sizing approach.
📌 Follow us/Contact us:
👉 www.xbosoft.com
👉 / xbosoft
👉 [email protected]
👉 +1(703) 995-9896