A Light in the Room

~ by Randy Wagner

One of the Challenging Aspects of the Software Development Lifecycle is Keeping Everyone on the Same Page

BAs write requirements, Developers design and code, QAs write tests, and the Product Owner (PO) gives the final blessing or requests rework, hopefully to complete within the sprint. That’s an agile process but it sounds an awful lot like waterfall methodology. There’s room for each party to run in a different direction. So how do we keep everyone rowing in the same direction?

Team Members Work in their Lanes and Hope to Get the Release Right for Production

Everyone in the scrum team has work to do, usually as much as they can handle in a sprint. Ideally, the BA is documenting complete and accurate requirements and then handing them off in a session with the assigned developer and QA. If they are all on the same page, there’s a decent chance of delivering correctly to the Product Owner. The PO, after all, is the final arbiter of what is acceptable for Production release. It would be great if the PO could be as present as the other agile team members but that’s often not the case.

What if we could replicate the PO in some way that gives the team a consistent mental view of the final product?

Business Acceptance Criteria (BAC) is an effective way to do just that. Well-written criteria provide the vision of the end result.  Each statement allows every team member to see the product in the same light as the PO, without getting bogged down in explicit requirements. It orients Development to solve the flow, rather than a narrow, technical issue. It helps QA gear the testing toward that end goal.

BACs can be Written in Different Formats

Many teams go with a Given/When/Then approach, while others prefer a rule-based structure.

The first, goes like this: Given that I’m an underwriting assistant, When I select the approve button, Then the system checks my authority limit and responds accordingly.

The second format is rule-based.  As an underwriting assistant, I want to approve policies within my authority limits, so that I can move the policy to the bind functionality. Within this may be a list of the limits, such as UW assistant can approve policies up to $2,500, cannot approve policies covering luxury items, etc. Both provide guidelines and allow for QA to write positive and negative test cases under and over limits or varying the coverages without getting too narrow.  And each acceptance criteria should be independently testable.

BACs Add Clarity to what the Final Product should be and Improve Sprint Planning

By providing the BAC in the light of how the user will work in the system, it gives everyone the same sense of expected behavior.  It also lets everyone know when the story is complete. Each story should have a few BACs. If we’re writing 7, 8, 10 criteria, we should probably split the story. Include functional and non-functional so that everyone gets a flavor for the vision of how the page should appear. And when we are done, it also helps in sprint planning to estimate the story.

BACs Show the Product Owner’s Vision and Keep the Team Moving in the Same Direction

By writing the BAC up front, it’s like turning the PO’s brain into a light that illuminates the room for the duration of the story.  They keep everyone on the same page and enable the team to deliver a product that the PO will readily accept. Make that light nice and bright.

_____________________________________________________________________________

Randy Wagner is Director of Quality Assurance for CastleBay Companies. He has 20 years of consulting experience across private and public sectors, Guidewire InsuranceSuite, InsuranceNow, and Duck Creek, with specializations in quality assurance, project management, configuration management, and automation.