Adding Test Cases to User Stories

In the last video, we looked at how to write user stories. How to move forward from problem scenario, to epic user story, to child user stories. And now, we’re going to look at techniques that we use to layer even more detail into that. So, we’ll have a look back at this epic we’ve been playing with, and we’ll take a look first at this child story A, where Ted the Technician has a part number that he wants to locate it in the system. If we layer test cases, which you will see over here, against that, what we want to make sure that Ted can just put the part number in and search against the part number.

If, for instance, our system’s excessively rigid, and we always force everybody down the same path, and make him say the make, say the model and so forth, well, we’re probably going to get a system that Ted finds pretty frustrating and not valuable. Another thing that the HVAC and [INAUDIBLE] team learned as they went out and did their field work with the technicians was that it does occasionally happen that they put in a part number, order a part number and they end up with the wrong thing. Because they made a little typo.

So as we thought about that we had the idea here to put in some kind of descriptive information so that as they pull up the part before they order it they’re seeing a photo. They’re seeing at least a description, a type of part, anything that we can pull from the data that we have, to help them avoid ordering the wrong thing. Let’s look at another example to kind of strengthen our understanding of this. So we’ll look at this story D. So Ted has found the part that he wants, and he wants to make sure that he has enough information to figure out his next steps.

So he can go talk to the customer and his dispatch to figure out what he’s going to do. Go get the part somewhere, have somebody bring it to him, schedule another appointment. So we also learned when we were out in the filed something pretty important. Some customers of HVAC and they actually stock their own parts or order them directly from the HVAC equipment vendors. So it’s not always the case that the HVAC and is going to order the part for the customer. So how are they going to make that work? Well, we saw that Ted will typically write it down for them, or maybe sometimes type up an email.

So we’ll make it possible to dispatch a request about the part number over email and log that so that the customer can go and get back to Ted about whether they have the part, whether they want to HVAC and hurry to order it or what. Now, this did bring up an important thing that we’re not going to sweep under the rug, which is that maybe we now need to look at some of our workflows and triggers, because we’ve kind of assume that the way things generally work over the course of our ethics is that HVAC in a hurry finds a part they need to order. They order it, they find out when it’s coming, they make arrangements.

Well now, we need to make an allowance where that part’s coming from somewhere else. So we made a note here. So this isn’t exactly a test case, but it is perfectly okay to make notes to yourself and to your team here. And it’s much better to err on the side of just writing things down so that you don’t forget. In this video you learn how to supplement the level of detail on your user stories with test cases. One thing I’ll say in closing is that think of these in this situation as kind of uppercase T, uppercase C test cases. They’re specific item that we’re using to layer additional detail against user stories.

Sometimes they’re called acceptance criteria, sometimes they’re called other things, in other sources you may read about Agile. Basically we just mean that these are a testable formulation that’s why we use this make sure thing that allows us to add additional detail to our user stories. Well, with that we’ll close. And in the next video, you’re going to see the HVAC in a hurry team go from problem scenario to epic stories to user stories.