Agile JIT Requirements and QA - Like Getting the Answers to the Exam before Writing the Exam

Tags: agile, scrum, tdd, qa, requirements

Read an interesting blog post by David Bleeker (What do you mean you don't have requirements?) that demonstrates how effectively an agile, self-organizing, cross-functional team can resolve challenges that come up in a project. In this case, the age-old agile conundrum of capturing adequate detail in the feature requirements to provide an audit trail to meet legislative or regulatory compliance.  David's team is exemplary in that the make-up includes QA members who actively participate in the Sprint planning process with the Product Owner in order to better understand how they will write tests to prove out each feature, who also provided the serendipitous solution for their audit requirements problem:

The QA team needed an amount of documentation—business rules, data elements, navigation—to understand how to test each story. They found themselves writing down key statements as the Product Owner rehearsed the story with the developers. Having been burned before, they also took to writing down the decisions made along the way. At the end of the rehearsal they distributed the documentation to the Product Owner and the rest of the team to make sure they captured the information correctly.

Since we were doing Test Driven Development (TDD), the QA team also took it upon themselves to provide the development team with mostly complete test scenarios for each story. As the stories were rehearsed, the QA team was busy identifying the specific elements that needed to be tested. These became the developers’ starting point. They coded the tests and progressed until they all succeeded, adding their own tests along the way.

The team was working off just-in-time requirements. There was no delay in getting the requirements documented. Instead the team started each iteration with a great deal of clarity. After a while some of the developers started coming up to me saying, “This is great! It’s a little like getting the answers to the exam before you write the exam.” The company also benefited from the collected requirements. We were able to demonstrate adherence to specific regulations through the log produced by the requirements.

This is a stellar example of how QA can integrate as active participants in the development team: Instead of being passive participants, they saw an opportunity to support the entire team and Product Owner by taking an active role in clarifying requirements with the Product Owner and Developers and then preparing them for just-in-time implementation.  I really like this strategy because it effectively demonstrates why agile teams are so effective at solving problems and how you don't need fancy or expensive tools to manage audit compliance.

What do you think? Feel free to provide your feedback below.

blog comments powered by Disqus