QA’s role in the 4 Agile meetings: ---------------------------------- Sprint Planning, Daily Stand-up, Sprint Review, and the Sprint Retrospective. In Sprint Planning, QA helps determine the Sprint scope by working to establish acceptance criteria for User Stories, estimating the level of complexity within each User Story, and detailing a preliminary set of tasks for each User Story. During the Daily Stand-up, QA discusses what got accomplished in the previous day, what will be the focus of work today, and if they have any obstacles that need to be removed. The Daily Stand-up is the pulse of the Sprint where the team communicates progress and QA plays an important role because they can define when Stories are “done done” which has a direct impact on the team’s burn-down. QA also plays a large role in a Sprint Review. Typically, QA will lead the demo within the Sprint Review and will show off the functional delivery for the Sprint. It is important that QA shows their total understanding of each story as they demo the product as it sends a clear message to the stakeholders that IT is working with them. In traditional SDLCs, post-mortems were the domain of the QA teams. QA teams were focused on process and analyzed what worked, what did not work, and made recommendations on how to fix it. In Agile, this review is the responsibility of the team in the Sprint Retrospective. This meeting should be where QA shines as reviewing process is an activity that QA is engaged in all the time. Now let’s focus on what day-to-day responsibilities look like for the QA team within an Agile environment. Most QA activities within Agile are NOT different from other methodologies. Agile QA teams still analyze requirements (user stories and acceptance criteria), create test cases, execute test cases, engage in the defect resolution process, and look for automation integration. The difference in Agile QA comes in how these activities take place. When working on day-to-day tasks, QA teams do not sit in isolation; they are collocated and collaboratively work with the Development Team to complete tasks as efficiently as possible. For example, when the QA team identifies an issue, their responsibility is to gather all the necessary details and log them into the issue tracking system but their responsibility also extends to having an immediate conversation with both the BAs and developers to assess the issue. In most cases, a resolution for the issue is determined within the conversation and the entire team is made aware of the ramifications of the change. Everything that the QA team does within Agile is predicated on the concept of the immediate feedback loop. Since everything the QA team does within Agile is predicated on the concept of the immediate feedback loop, where does that leave the need for QA metrics? In more traditional SDLCs, the QA team is responsible for regularly providing comprehensive status reports full of metrics. However, in Agile where one of the central tenets is working software over comprehensive documentation, the QA team is not as obligated to provide regular, exhaustive status reports and metrics. The Scrum Master is responsible for providing the team with a Sprint burn-down chart and a Project burn-up chart which serve as the key information radiators for the project’s overall health. If comprehensive status reports are requested of the QA team, seek out the Scrum Master and have an open dialogue about what value the report has and whether or not that value supersedes completing the Sprint work. In most cases, reports will not serve to provide any better details then what is already being provided and if the reports are necessary, the work to create them may fall on the Scrum Master more than the QA team. To summarize, much of what QA teams do in Agile is not significantly different from more traditional methodologies; the difference lies within how the QA teams accomplish their responsibilities. 1) First, QA teams need to be focused on lean, flexible process, tools, and documentation which comes in stark contrast to traditional QA methodologies. -------- 2) Secondly, QA teams need to be focused on a collaboratively working environment, one focused on trust and doing things for the betterment of the team. -------- 3) Finally, QA teams need to embrace the idea that getting tasks completed as quickly as possible dictates that they ask themselves what value each work task provides. If a task holds little value or does not move the team forward, work with the Scrum Master and the team to decide whether or not the task can be eliminated. ---------- Ultimately, being a productive Agile QA team member requires a little retraining on what is most important to the project: quickly having a quality releasable product.