How to Create Valuable User Stories
Get Your Testers Involved in Acceptance Criteria
FOUR FREQUENTLY ASKED QUESTIONS
I recently had the honor of presenting a series of webinars on “Writing User Stories and Slicing Epics for DW/BI Teams” for Cutter Consortium, where I am a senior consultant. After each webinar, I addressed questions from the audience.
Here’s another popular question and my answer.
Question #3: “What’s an example of good acceptance criteria — outside of that the report should match the mockup/data should be accurate.”
LW: Acceptance criteria is a big topic. A simple example can be seen in figure 2, in the most profitable transactions.
Figure 2 — Watch Out for Epics
We’ve simplified it down to where we need to see profit per customer per transaction, so that we can identify the characteristics of the most profitable transactions. One example is when XZY manufacturing places order number 13579 for 3 widgets for $100 each. This is our acceptance criteria. They’ve placed an order for 3 of our products at $100 each, and the widgets are on sale for 10% off, and the cost of goods sold for each widget is $50, then the profit for this order should be $120.
If you do the math, that works out that $300 less 10% ($30) less $150 = $120. This is what’s called behavior-driven development. This is a format. When something happens, and it has X criteria, and it also has Y criteria, then Z happens. It’s a great method in the data world for the stakeholders and product owner to clarify what they mean and what they’re expecting to see. In this case, you might have several different scenarios — and this could come out of a use case scenario — so you might have a handful of these examples.
And I like it when the person requesting this, the stakeholder, comes to me and says, “Okay, here are five orders that I’ve picked out of our system and they each meet a different criteria. This one has 10% off. This one has $5.00 off each. This one doesn’t have any discounts.”
And you would even want one that says, “If the cost of the product, less the discount, less the cost of goods sold, is negative, we want to know that it was a negative profit.”
So it’s good to come up with a handful of examples that flesh out what they want to see. It gives you test data to unit test on, and you can automate that. So when you have an actual order, where they say, “Run this through and here’s what I expect the profit number to be,” then you can automate that very easily. You can say, “Here’s the input of this order with these elements and here’s the expected profit that’s going to calculate in the end.”
That’s a beautiful way to go.
However, it is very time consuming. And it can feel completely overwhelming to some teams who aren’t set up to do that. It’s very useful to have the testers involved, or someone with testing skills involved because he or she can say, “I see your story, here. Let’s pull a few orders out that meet these scenarios.” The testers can get going on writing the tests and getting the test data set up and automating those tests right away before the developer even does any development.
That’s a great way to do it.
COMING UP ON LYNN’S BLOG:
LYNN ANSWERS THIS POPULAR QUESTION:
Q4: What is your recommended sprint length for a data warehouse team given the fact that it takes longer to deliver a Data warehouse solution?
Share in the Comments:
Do you have a tester you can include on your team from the beginning? How are your stories? Do you wonder if you have an epic? Post your story here and let’s discuss as a community.