As a product owner, I am constantly challenged with writing user stories that meet my stakeholder needs. A key deliverable from a Product Owner is having user stories with crisp acceptance criteria. Having clear acceptance criteria enables the scrum team’s ability to deliver high-quality software. It also enables the team to make commitments toward sprint goals while ensuring that the business is getting high value deliverables based on the decomposition of the highest priority epics. The challenge in writing good user stories is always the amount of details to add to a user story. A good user story should have enough details to understand the business intent, the user roles, the goal and the depth so that the team can understand it to produce a workable prototype or software and the business can understand it.
I run into team members, or manager or business stakeholders, who constantly want to write more “requirements.” My initial reaction is always to ask the question – “who needs this detail?” and more than often as we discuss it turns out that it’s no more than a feel good factor for the person asking for the detailed level of documentation and the delivery team is truly not a beneficiary.
The following are 3 scenarios where I consider using Given-When-Then
- Describing Business Stories – as I represent the voice of business, my primary intent is to ensure that the user stories are defined with acceptance criteria that cover the scenarios under consideration. I have found that writing acceptance criteria with multiple scenarios and defining the acceptance for each scenario with Given-When-Then enable the team to decompose the user story and then define the test conditions that need to be met to call the story done. Further, we have found that if we decompose the user story into multiple scenarios, we find logical break points that allow us to split the user stories into smaller chunks that I use to negotiate with business owners to get clarity on the priority of a certain requirement compared to the rest of the backlog. This really helps me as a product owner to truly drive prioritization.
- Describing technical stories – I use given when then, for either UI or API stories (when we don’t need or cannot create a vertical slice). In this case, it really helps with scope containment of what the team needs to complete in order to deliver value.
- Regulated environments – user stories in these projects are exceptions and have to be treated as such. The intent to include the testers on the team as part of the acceptance criteria can substantially help with reducing testing cycle time as well as ensure that the regulatory intent is met. GWT statements make user stories easier to trace to tests and code.
I want to summarize by saying that in the end, the criterion to choosing comes down to individual preferences, here is a summary of conclusions:
- Focus on fundamentals – The 3 C’s – Card, Conversation, and Confirmation. Using given when then really enriches and helps structure the conversations that allow the teams to make a commitment.
- A benefit of following this process allows for user story split, which in itself is complex as the story has to be split in the right way such that each split produces a workable slice of software that delivers business value and the team can work on in one sprint and also allows the PO to prioritize
- Clarity of acceptance criteria truly allows the team to do good estimation during planning.
- Simplifies and enables the PO to accept the user stories.
- GWT translates well into automated tests
Learn more about building and strengthening an agile organization here:
Interested in training to help advance your agile journey? Click the button to view our current list of public training courses! Use code BLOG10 for 10% off!
