Conducting Agile Volleyballs

Agile Volleyballs refer to the act of validating a story implementation by a business analyst/product owner before testing. This is a non-standard agile/scrum ceremony but it is worth practicing as the ROI is quite high. They might also be called as a BA volleyball or just “volleyball”.

What is it?

A story implementation has the following sequence of activities. The BA validates the intent of the story. This means checking the happy path at a minimum. Once the BA confirms that the story is development done, it moves on to the quality analyst for testing. After it passes the quality check, the story goes for acceptance by the product owner. Finding a bug or a change in the implemented functionality becomes costlier the further down this path. The BA volleyball is a quick way of ensuring that the major part of the story works as expected while giving feedback to the developers about the story itself.

Who needs to be in it?

The volleyball will need the pair of developers who has implemented the story, the quality analyst(s) who will be testing it and the business analyst/product owner (BA) who has written the story.

Pre-requisites

The BA should know the application, feature, and story well. The BA should look at the story beforehand and understand that the intent and the acceptance criteria well. Prepare data, configuration etc. with the developers so that the story is ready for volleyball as expected by the BA if these are not already covered in the kick-off.

Time

Usually, the first few stories in a feature need a lot more preparation and time to volleyball. This is due to the set-up involved as well as the fact that the team is looking at the implementation of the feature for the first time. There is likely to be a lot of discussion between the developers, QAs, and BAs. Once this is over and the team is familiar with the feature, the time taken reduces quite a bit. Sometimes, the team will need more time for setting up the application for validation.

Kicking-off

The BA needs to make sure that the set-up is done as per their data/inputs. Have the application open in one window and the story in another. Also, have pen and paper or be near a whiteboard for any conversations/follow-ups that may be needed.

The BA should be in full control of the interactions with the application. One common mistake is to allow the developers or the QAs to demo the story for the BA. This is a big no-no as it does not allow the BA to get a feel for the implementation.

Use the application as a novice user would, without looking at the acceptance criteria. This allows the BA to experience the usability of the story implementation itself as well as giving them feedback on the functionality. Make notes on improvements and changes as needed. Next, check the implementation while going step by step through the acceptance criteria. This will give better feedback to the developers and QAs on where changes will be needed if any. Validate the assumptions of the story also and add to it if there are any new ones.

Usually, there will be some changes. Most of these will be trivial (minor UI tweaks). With a good pair of developers, the volleyball should be a cinch, provided the acceptance criteria are consistent within themselves and with the rest of the application. There might be times where the acceptance criteria itself needs to be tweaked. The BA can then take a call on the future of the story implementation along with the rest of the team.