An Epic Experience with Agile

By Debbie Kerr

While I am a technical communicator, my role on projects is as a business analyst and not as a technical writer. My focus is on working with subject matter experts (SMEs) to identify the requirements that will be used as the basis for developing software. This is part of the Agile Manifesto: to put customer collaboration over contract negotiation.

For my current project, there are epics, user stories, and detailed requirements. These requirements are part of the process of converting a paper application to a web-based one. The paper application is 30-pages long and has 23 sections, a large number of fields, associated business rules, and an extensive series of validations both within screens and between multiple screens. In general, the epics are the 23 sections that have to be completed in the application. There are approximately 15 user stories per epic and the detailed requirements are all the fields, functions, business rules, and validations. These requirements range from about 10 to 20 pages per section.

Normally, in a Waterfall project, these detailed requirements would be completed from start to finish before development begins. With this project, I write the requirements in iterations, although it can take me several cycles to complete the requirements and receive signoff. There are formal signoffs; however, once development starts, sometimes it becomes necessary to add or modify requirements. I usually capture these requirements in emails with a less formal approval process.

In addition to formal requirements there are also functional specifications that a Business System Analyst prepares after the detailed requirements are signed off. In some cases, the requirements that I write contain enough information that separate functional specifications are not required. This practice is in keeping with the Agile manifesto: to place working software over comprehensive documentation.

An Agile approach means being able to adapt quickly to change. Recently, the day before a demo was scheduled to occur, we discovered that there was a misunderstanding about how something was supposed to work. Since the development was being completed in three-week cycles and the demos for the previous cycles were successful, the amount of change required and the implementation of those changes could be done much more quickly than if it had been a Waterfall project, where the problem may not have been noticed until much later in the development stage, and even as late as the testing stage. Since retrospectives (a type of lessons learned) are completed at the end of each cycle, we were able to identify ways to improve our processes going forward so that this problem does not occur again.

As cycles are completed, a Quality Assurance (QA) Specialist tests the software that has been developed in the previous cycle. Sometimes this testing is automated so that it can be repeated multiple times over the course of several cycles.

In addition to QA, there is also User Acceptance Testing (UAT). This testing ensures that key people can use the software to complete the tasks that they normally perform in their roles. Some of this UAT is being done as part of various cycles and the rest of it will be done when all development is complete. This is considered end-to-end testing and is often associated with a Waterfall Software Development Life Cycle (SDLC). For my project, this type of testing is required because, until all 23 sections have been developed, the completion and submission of the entire application cannot be tested.

Like any project, it will be epic when everything comes together. It will be even better when it is implemented and people begin to use it.