The next topic on our series of articles on Agile best practice is looking at requirements and how they are managed through the scoping and development lifecycle. Requirements are at the heart of any IT project, they’re the starting point and drive why the project exists in the first place. Yet, capturing requirements is a challenging affair, and the question crops us more often than I can count: how should requirements be written? Sometimes with an Agile twist: how to write User Stories?
Take the following example, taken from the real world, in an e-commerce implementation:
“Clicking the Back button should not disrupt the user journey on the site”.
And the corresponding User Story:
“As a visitor browsing the website catalog, i want to be able to click the Back button of my browser and not be disrupted in my journey on the site, so i can browse effortlessly.”
Consider for a minute that a retailer is contracting a 3rd-party agency to build their brand new e-commerce website. In the example above, the development team can read the requirement and build something they think is right, while the retailer wanted something different, or even something larger. The requirement captured above obviously isn’t clear enough to be sure of what is needed. But the project plan and the contract precisely depend on a clear and common understanding of core requirements; any grey area can result in misunderstandings, Change Requests, which can all lead to project delays, additional costs, difficult negotiations between parties.
Requirements are usually captured in the following ways:
- a spreadsheet with rows and rows of requirements written using short descriptions, otherwise known as the Requirements Catalog,
- a documentation space containing detailed descriptions of each requirement, with architecture diagrams, flow diagrams, user experience, wireframes/designs,
- a list of tickets for the development team to progress (captured in software such as JIRA), otherwise known as the Product Backlog.
In a perfect world, one should be able to track any item of the requirements catalog all the way down to its corresponding ticket in JIRA. A project lead must be able to know that all requirements are tracked effectively, progressed, and satisfied exactly as they were defined upfront. In projects involving a customer-supplier contractual relationship, this becomes yet more critical for obvious reasons: as a customer I’d want to make sure that my supplier has captured all the requirements in JIRA tickets. As a supplier I’d want to make sure the customer doesn’t extend the scope of those requirements during development.
But what we see in the real world is pretty different. Ambiguities start appearing early in delivery, almost every time. Scope creep is almost inevitable, Change Requests are written as soon as the scope has changed substantially, and we either find a customer who feels they’ve paid more than they should have, or we have delivery teams feeling frustrated that they’re burning time to ensure they deliver what’s required.
Moreover, when it’s time to conduct acceptance testing, we find yet more differences between what the customer requested and what has been delivered by the supplier; testing needs to be adjusted and repeated, incurring additional efforts and costly delays. Final acceptance is the critical phase where requirements are met (happy customer), or where a project plunges into delays (contractual negotiations, penalties, etc).
In Agile culture, we seek to capture “Acceptance Criteria” as part of every requirement before any work can start. In short, Acceptance Criteria is a precise and complete definition of how a requirement will be verified and accepted as “done and delivered”. Acceptance Criteria can be written in a number of ways, but the most effective is to simply write a set of scenarios that will be used to verify that requirements have been met.
Example of a single scenario: Given the user is on a search results page, and has clicked on the product image thumbnail, and a lightbox opens with the large image, when clicking the back button on the browser should close the lightbox and leave the user on the same results page.
Writing Acceptance Criteria doesn’t solve everything because the key aspect is reaching formal agreement upfront by what the Agile world calls “The Three Amigos”. They are:
- Product Owner or representative of the Business (the customer)
- Technical Lead, or representative of the engineering team (the supplier)
- Testers, who formally conduct acceptance (customer and supplier)
In an Agile delivery model such as Scrum, scenarios should be agreed by The Three Amigos while we prepare the next Sprints’ tickets. The Product Owner should prepare the scenarios, and pass them to Technical Lead and Testers for discussion and validation. When this process doesn’t take place, projects run the risk of having a Product Owner who expects something, an engineering team that builds something else, and a testing team that is confused as to what they are meant to validate and how. The idea here is collaboration, transparency, common understanding, focus. Simply put: Agile.
In a fixed-price client-supplier context where requirements drive the total project cost, the contract and delivery plan, agreement on all Acceptance Criteria by The Three Amigos upfront, during discovery guarantees a common and precise understanding as to what is to be built and delivered.
The benefit to the customer is obvious as it gives the opportunity to dig into their requirements in greater detail, it often uncovers aspects that weren’t obvious upfront. The supplier can get a better understanding of what is required and can size and cost each functionality with greater accuracy. Final acceptance then becomes a smooth process, as all scenarios are already documented along with each requirement. Project delivery simply becomes a better experience for all parties.
By Jonathan Lhrar