As Agile becomes the default approach to software development, it’s easy to start going through the motions without paying too much attention to the underlying rationale and beginning to let some of the steps slip. In my experience as a Test Automation lead working with a variety of Triad clients helping them produce higher quality software efficiently, Agile meetings or “ceremonies” are a key part of successful Agile development.
In this article, I’m going to run through the rationale for them and then focus in on the different aspects that maximise the Quality Assurance aspect of a development project, although doing these well will undoubtedly benefit the entire project.
Perhaps Agile ceremonies’ loftiest and more critical role is that they should bring transparency to the team and set a common goal and vision. These ceremonies help the team solicit feedback, assess their progress, and align what they are doing with the needs of the client. These ceremonies should ensure that everyone in the team are in-sync, making it important for the whole team including Business Analysts/product owners, the development team (developers and testers), delivery managers/scrum masters and stakeholders are involved. Agile ceremonies play a key role in improving the product and process quality – everyone should believe and commit to that and deliver their own participation.
The Agile ceremonies that are particularly important for Quality Assurance:
Backlog refinement meeting
Backlog refinement is the act of adding detail, estimating, and prioritising the items in the Product backlog. This is an ongoing process in which the Product owner, stakeholders and the development team collaborate to steer the product in a way that delivers the most value as early as possible.
During the product backlog refinement, items are reviewed, revised and acceptance criteria are updated depending on the common understanding of the requirements. It is advised to conduct the refinement meetings on a regular basis, ideally every two weeks. This helps to improve the quality of the requirements and to have a prioritised product backlog ready for development.
In Agile Scrum the backlog refinement needs to be done before the team goes into the Sprint planning meeting. This gives an opportunity to verify that the user stories meet the ‘definition of ready’.
A ‘definition of ready’ is the set of criteria agreed amongst the team in order for the story to be considered ready for development. A definition of ready could stipulate for example, that the story should contain a proper description and a summary, that acceptance criteria are complete, relevant screenshots or wireframes have been attached, and business rules have been fully documented.
The team can also do Bug triage as part of this meeting and add any bugs into the backlog depending upon the priority. Bug triage is a process where each bug is prioritised based on its severity, frequency, risk, etc.
In my experience, most large-scale issues that arise in software development projects start due to poor or gaps in requirements, refinement meetings are used to improve the quality of the requirements.
Sprint planning meeting
The product owner, stakeholders and development team meet and review the prioritised backlog. The team discuss each user story to get a clear understanding about how to implement the user story.
The Sprint planning meeting happens before every Sprint and the goal of Sprint planning is to answer the questions “What are we going to work on, and how we are going to do it?” The team creates a Sprint backlog with the list of items from the prioritised product backlog that they plan to work on during the specific Sprint.
The development team will add more technical detail about the implementation of the user stories and create sub-tasks such as implementing backend changes, front-end changes, creating automation test scripts, etc. under each user story so that everyone in the team know what they need to do in order to complete that user story.
The planning meeting helps the team to understand the requirements and to know what they need to do in order to implement the requirement. The most successful projects take prioritisation, with all views considered, extremely seriously. When it comes to the QA phase of a project if just the technical agenda has been reflected cracks and change control issues often arise. So, again active engagement throughout the project is key to ensuring a high-quality output and smooth QA process.
Daily stand-up meeting
A time boxed meeting (ideally 10 to 15 minutes) happens every day where the product owner, stakeholder and the development team meet to give an update of their work. Each person provides highlights of the previous day, planned work for the day, and any blockers that may hinder them, their team or the delivery.
It’s called a stand-up because the team stands the whole time, encouraging the meeting to be speedy as it is time-boxed to 15 minutes. The stand-up meetings are typically held in the same location and at the same time each day.
Daily stand-up meeting helps to get transference in the team and to see how the team is progressing to meet the sprint goal.
Sprint review / show and tell / demos
It is advised to have regular Sprint reviews, often called show & tell sessions. These should be held at the end of every sprint (typically every two weeks) to showcase what has been achieved so far, what is likely to be the goal for the next phase, and to highlight any risks/issues. This meeting is focussed on the product, rather than the process and the Product owner, stakeholders and development team should all participate.
These show and tells, give an opportunity for the development team to demonstrate the work they have completed so far and to get feedback from stakeholders and end users. The feedback from this meeting can be useful for the team to reprioritise the product backlog, add new requirements into the product backlog, and to alter and align the teams working process to fulfil the client needs.
Retrospective meeting
This is the meeting where the development team and product owner get together to discuss how the last phase of development was handled. This focussed on the process, rather than the product. The retrospective will be used to gather thoughts on how the sprint went, and then discuss actions to improve the team’s welfare/ways of working/process etc.
The team should identify what they felt went well (celebrating success), what didn’t go so well (what are the opportunities), and what they can do to improve the process next time around (Even Better If).
The retrospective is an important mechanism that allows a team to continuously evolve and improve throughout the life of a project. During this meeting efforts are made by the team to find effective solutions to problems and to develop action plans.
Other stakeholders ‘may’ be invited to the retrospective, but it is unconventional to have ‘management’ attend. This is because it is a meeting for the team to discuss issues in a safe environment without being led by management or feel held back from expressing concerns.
Conclusion
Agile ceremonies are an important part of Agile development. In Agile, requirements and solutions evolve through collaboration between self-organised cross functional teams and stakeholders. This makes it important to have a regular interaction between QAs, developers, product owner, stakeholders and the end users through daily stand-ups, planning meetings, backlog refinement meetings, regular demos and retrospectives.
These ceremonies bring a lot of clarity into the requirements and a better understanding about the work that is expected from the team. Conducting these ceremonies correctly will help the team to improve the quality of the process and the product, constantly.
In my experience, most large scale issues that arise in projects start when these meetings are not conducted effectively and when the participants in these meetings have skipped or not fully engaged. As such, it is worth reflecting on how well your Agile ceremonies are run and ensuring everyone understands the different purposes of each and feels equipped to participate fully.
Venu Botla, Consultant
Triad Group Plc
