As all good Scrum coaches know, backlog refinement is an important part of the team's sprint cycle, and as important a component of Scrum as any of the Scrum ceremonies. It allows the team to share its thoughts, forces the team to broach fundamental concerns, and, most important, it allows the team to gain an improved and common understanding of the work flow. In my experience, many teams fundamentally fail to realize the detriment they cause themselves, and the benefits they miss, by not refining the backlog on a regular basis. Even mature teams sometimes feel that it's OK to leave this out of their sprint cycle, and those who want to do it seldom understand the best way to achieve a sensible level of backlog refinement. I've had successes that have led me to use Behavior-Driven Development (BDD) as a staple part of backlog refinement during my sprint cycles.
BDD is a means of applying business language to acceptance criteria, and thus test cases, that helps the business and IT functions understand what's being developed, down to each unit. BDD is written in the Gherkin format of "given-when-then" statements. Let's explore how teams can use BDD to support product backlog refinement.
During the sprint, the team looks ahead at the PBIs (product backlog items) coming up in the next sprint. We find the PBI order has changed and that the team doesn't have enough time to review the PBIs more than once. The QA, developer, and product owner should meet to discuss and write out the conditions of acceptance for the next-highest priority PBI, using the BDD format of "given-when-then" for each scenario.
I think we need an example here. So the PBI might read:
"As a customer, I want to log in to the website so that I can view my profile."
The product owner is expected to have added some high-level acceptance criteria for this story. This usually works best captured on the back of the physical index card, and it might read:
- Customer must be able to log in using username and password only.
- Customer must be given an appropriate error message when he or she enters an incorrect user name or password.
There are likely to be many more conditions of acceptance, but let's keep it simple for now. When the QA, developer, and the PO meet to discuss the first PBI, they will review the conditions of acceptance and collaboratively compose all known scenarios in BDD format, which might look something like this:
- Given that I am on www.[WebsiteNameHere].com and I can see the username and password text box,
- When I enter my user name and password and press the submit button,
- Then I am presented with my profile.
This is one simple scenario, and as you've probably guessed by now, there are many other scenarios the team will collaboratively work through. It's important to note, however, that at this point it isn't expected that every single BDD scenario will be captured, and I wouldn't want this session to be a drain on the team. The purpose of the session is to be a quick review of what scenarios are needed. Usually the QA would compose the complete list of BDD scenarios to help during the next refinement session. A sensible way for the team to approach this would be to start defining a healthy set of BDD scenarios during each refinement session, adding to the list at every session until (usually during planning) they have most, if not all, scenarios captured.
It's up to the team to decide when it wants to start and what the frequency of the refinement sessions should be during the sprint. Ultimately the team will naturally fall into a sensible rhythm and adapt to the changing landscape. As a coach, you must ensure that the team keeps up with its refinement sessions and set reminders.
What's exciting for me is how BDD can positively support the teams' and stakeholders' understanding of what is being delivered in simple business language. Furthermore, the application of BDD goes beyond what we've discussed here. BDD is the bedrock of automated testing, and even if the teams are immature in their understanding and application of automated testing, using BDD on a daily basis will form a great foundation. Automated tests use feature files, which are formed of BDD scenarios.
Ultimately, using BDD for backlog refinement in Scrum works to bring the stakeholders together in improving their understanding of the system, giving them confidence in the project approach and the adaptability of Scrum as a framework. It's also a great way to get your team working well on many levels, not just the obvious in terms of backlog refinement but also in pushing it to communicate regularly. It supports healthy team discussion and thus allows the team to bond and grow.
This diagram is an example of when a team might decide backlog refinement sessions should take place during the sprint cycle. This assumes the common two-week sprint cycle.