Agile Does Not Mean "No Requirements"

In the first post in my series about Agile Software Development, I discussed the most common misconception that our clients have about Agile. Specifically, we often hear the assumption that there is no planning or analysis when preparing for an Agile project, and that the development team starts building the application immediately. In today's post, I would like to address another common misconception about writing requirements and the process that our team uses to gather and record requirements in order to deliver high quality Agile projects.

Agile Misconception #2: “There are no requirements. Just start coding!”

People who hold this untrue belief about Agile have likely participated in waterfall-style projects and have experienced the pain of never-ending and politically intense requirement meetings. They also have likely created or reviewed voluminous requirements documents that were virtually unreadable or did not actually reflect what the software should do. People who experience this pain associated with waterfall development often look to Agile to make the requirements process simpler. However, if they swing too far in the other direction - gathering no requirements and immediately starting development without any understanding of system - they will likely suffer a different kind of pain and will almost assuredly fail.

At Tribridge we use a structured, albeit lightweight, process for gathering software requirements. First we start by identifying user stories. A user story is a short description of desired functionality that is written in plain English from the perspective of the user, not the system, and is much easier to read and comprehend for our clients. We capture as many user stories as possible at the beginning of a project so that we can provide a reasonable estimate as to the total project cost and time frame, and so that we can begin formulating a vision for the technical architecture. After the stories are captured, they are prioritized and assembled into a “product backlog,” which is provided in written form to our client.

Second, we dive deeper and identify the “acceptance criteria” one at a time, for the most critical user stories. Acceptance criteria are the details of a user story that define what the software must do in order for that story to be considered “complete” and acceptable to the users. It allows us to identify the various scenarios that must be coded and tested, which ultimately allows us to refine our estimates and proposed architecture. We do not spend much time identifying detailed requirements for less critical user stories that will likely be created months into the future.

One of the key distinctions between a traditional waterfall project and an Agile project is when the requirements are captured. With waterfall, all requirements are captured at the beginning of a project. With Agile, high level requirements, which are like project goals and are therefore relatively stable and unlikely to change, are captured early in the project. Capturing detailed requirements is delayed as long as possible, often just before the feature will be built. This ensures that the requirement has not become obsolete due to changing business needs or simply the passage of time, and the time spent capturing the details of the requirement was not wasted.

Perhaps more importantly, the requirement remains fresh in the minds of the team and likely still linger on a whiteboard near the development team. Therefore, time does not need to be spent formally recording the requirement into a document since the time between when the requirement was discussed, and when the code will be written and tested, can be measured in days as opposed to months, as is the case in many waterfall projects.

With all custom software projects at Tribridge, it is imperative that we understand some level of the requirements of a project before we get started. This allows us to perform solid analysis and planning, ensure that the project is budgeted and staffed appropriately, and that the architecture will support sustained growth and scalability. By using Agile techniques, we do not need to capture every single detail of every feature before development begins, which saves our clients time and money. Fleshing out the details closer to development allows us to embrace change easier, and allows our clients to provide feedback regularly throughout the project, all while cutting out unneeded documentation along the way.

Efficiency is something we pride ourselves on here at Tribridge, and implementing Agile techniques is one of the ways we ensure our clients always get a thorough solution without unnecessary costs.

Next Post