Play Now:

Get PMI Agile Cerfified Practitioner (PMI-ACP)® Training on your phone:

Betsy Stockdale and Cornelius Fichtner

In agile, technically anyone can write user stories. Sounds easy, right?

However, many people really do not have a good understanding of how to write high-quality stories or effectively manage the product backlog. In this interview you will learn about the full life cycle of agile requirements, including how to use visual models at each step of the iterative process.

This interview with Betsy Stockdale (LinkedIn Profile) was recorded at the inspiring Project Management Institute (PMI)® Global Conference 2017 in Chicago, Illinois.

We explain the life cycle of agile requirements and how to use visual models to identify epics and user stories, and how to write testable acceptance criteria using a variety of techniques. Those currently working on their PMI-ACP training will find this interview valuable for their general understanding of Agile approaches.

Episode Transcript

Below are the first few pages of the transcript. The complete transcript is available to Premium subscribers only.

Podcast Introduction

Female Voice:   In this episode of the Project Management Podcast™, we will look at the life cycle of Agile requirements and how to use visual models to identify epics and user stories.

Podcast Interview

Cornelius Fichtner:   Hello and welcome to the Project Management Podcast™ at www.pm-podcast.com. I am Cornelius Fichtner. We are coming to you live from the inspiring 2017 PMI Global Conference in Chicago. And with me right now is Betsy Stockdale. Good afternoon.

Betsy Stockdale:   Good afternoon.  

Cornelius:   How has your conference been so far? You look very chipper.

Betsy:   Oh well. Of course. Because it’s really great to be here and it’s really fun to listen to a number of these different sessions and just get inspired on things that I might be able to take back to the office with me.

Cornelius:   Wow and I used the word “inspire” just a moment ago.

Betsy:   Yes, you did and that was not planned [laughs]

Cornelius:   Completely not. So, what have you seen so far?     

Betsy:   Oh well, the keynote was awesome, obviously and then there was a couple of others especially around Agile and I’m definitely working in an Agile world these days. So, just you know, attending some of the sessions with regards to Agile and really trying to pick up some tips and tricks that I can take back to my organization and my team.

Cornelius:   The energy is really fantastic this year. I’m really excited to be here, yeah. Let’s move on to your presentation. Have you already presented?

Betsy:   No, I’ll actually present tomorrow afternoon.

Cornelius:   OK. Your presentation is about “Not Your Mama’s Acceptance Criteria: A Guide to Writing Excellent User Stories”. Now at this point, we have to make one thing clear—you’re not a project manager. You’re a business analyst?  

Betsy:   I am.  

Cornelius:   Yes, you are our backbone. You’re the person we can’t live without.

Betsy:   I like to think so.   

Cornelius:   Yes, absolutely. [laughs] 

Betsy:   [laughs].   

Cornelius: “Not your Mama’s Acceptance Criteria—two words—acceptance criteria: A Guide to Writing Excellent User Stories”—how do these four words—acceptance criteria and user stories—how do they match together?

Betsy:   Well, it’s –in this Agile world, we really are looking at writing our requirements in a different format so instead of the system shell statements, over and over and a thousand times over, we’re really using much more of a natural language to write our requirements and that’s the user story part. So that’s very helpful in terms of understanding what it is that –who our user is and what are they trying to accomplish but the meat of the material is really in the acceptance criteria.

That’s what really helps us understand what is it that our folks are trying to accomplish and it really helps our developers understand what it is the software needs to do and the testers, they understand what to test.

Cornelius:   So, in other words, the acceptance criteria are part of the user story.

Betsy:   They are. They are.

Cornelius:   OK, good. What is your interest in this topic?  

Betsy:   Well, as a business analyst, this is like essentially my core and this is what I do all the time. I’m writing user stories and I’m writing the acceptance criteria to go along with them but I also want to really make sure that I completely understand what my stakeholders are looking to accomplish and what their objectives are because I want to make sure that whatever—the requirements that I’m writing reflect that to make sure that they get software that is valuable, and beneficial for them.

Cornelius:   And how important are user stories with good acceptance criteria in your day to day work?

Betsy:   They’re indispensable. Without it, then who knows what our developers would come up with? [laughs] They get creative if you don’t give them an idea of what it is you’re looking for and that may not be a good thing.   

Cornelius:   Your presentation centers around a process—Identify-Elaborate-Refine-Ready—in order to get to a good, well-written user story that includes those fabulous acceptance criteria. Is this a standard process? Where does this come from?

Betsy:   It is, in my mind anyway and my co-workers at C-Level and it really is helping us understand that just because we’re Agile doesn’t mean that we just start writing requirements. There’s a whole process to understand and figure out what it is that we do and I think a lot of times especially in the Agile space, people forget that. It’s not we just start developing whether for Sprint, you have to have that product backlog and that product backlog has to come from somewhere.

So, this process is really about understanding what is it that needs to be in that product backlog in getting to that point, so that way we have the backlog ready for our first Sprint.    

Cornelius:   OK. So, we have Identify, Elaborate, Refine and Ready. Identify has four sub steps, Elaborate, two, three rather, Refine has three, Ready has two –how much time do you invest in the user story in order to get it to Ready?

Betsy:   [laughs] Oh it kind of depends. But you know I think on average, you can probably look at it and say that every user story probably takes three to five minutes each if you are looking at it from beginning to end. Now obviously it’s a very iterative process. We’re going to do a little bit and then we’re going to do a little bit something else and then we’re going to do a little bit more before it’s actually all ready to go and there’s always more than one.

So, if you probably look at it from that beginning to end, three to five minutes per story is about right.

Cornelius:   3 to 5 minutes!

Betsy:   Uhm.

Cornelius:   You are very quick. It takes me days to write user stories. Alright. Let’s begin with the beginning. Identify. What do we do in the Identify?

Betsy:   Identifying is really getting down to understanding what it is that the business wants to accomplish. All of our projects that we’re working on, we’re trying to either take advantage of an opportunity or solve a problem. And so, I need to understand what that opportunity or that problem is in order for me to be able to move forward or actually the whole team to move forward.

So that whole Identify section is really getting a good understanding of that because without it then we may build something that doesn’t meet the needs of our business.

Cornelius:   At that point if I identify, I’m probably at a pretty high level –that means we’re writing epics at that moment.    

Betsy:   Absolutely. Yes. And we could even be higher than epics. It could be an initiative or—pick your word but yes, it’s extremely high level. Let’s start figuring out what is it that we actually need to build.  

Cornelius:   OK. Process flows are also part of this.

Betsy:   Absolutely. Because we’re going to be using the software as part of their business processes so if I don’t understand even at that high level with that business processes, then I don’t understand how they’re going to use this software or how they are going to use it to take advantage of that opportunity or solve that problem.     

Cornelius:   And how about business objectives?

Betsy:   That’s all part of it. That’s actually at the very beginning so we like to create something called the business objectives model which really helps us understand what the problem is and how we think we would solve that problem or what the solution will actually look like.

Cornelius:   Is all of this happening before the official and I’m making air quotes here –the “official” project has started? When do we get into this?

Betsy:   It really depends on how you define the start of the project. So, in the purest business or like a Project Management world, this is probably all part of the project charter and really have an understanding, again, what is it that we’re attempting to accomplish here?

Many times, I don’t see so many charters anymore and so if I don’t have this information available for me when I show up on a project, then I feel it’s incumbent upon myself to go back and take those few steps back to say, “No, I need to understand this” because otherwise, I’m not driving towards the solution and I’m wasting everybody’s time and money and I don’t want to do that either.

Cornelius:   And how do people react when you do that?

Betsy:   It depends on who they are. Senior managers, actually are pretty good about it. Especially if I told them that a lot of times I’m doing this to make sure that I can control our scope and not worry about the extra stuff that people all get excited about or that they may want us to build and that we’re going to focus on really making sure that we build a solution for them. They’re very, very welcoming.

Middle managers, especially people who think. “No, we just need to get going”—maybe not so much [chuckles] but most of them understand. So, it’s usually pretty well-taken.

Cornelius:   OK. So, in the Identify process that we have –the four sub processes ---understand the objectives, identify and prioritize features and then create the process flows and the last one seems easier said than done, I say, it’s identify user stories—how do you identify the user stories because at that point, you have such a big thing in your head. How do you now go from all of this? How do you break it down?

Betsy:   Well that’s where actually a lot of just the objectives and even the user stories help us understand well what is it that these—what are these high-level things? We also create something called the Feature Tree which kind of helps us start to think of what those high-level features are and break it down into smaller bits.

All of this actually helps us create the user stories and even like a story map. Here is like our high-level process, here’s the features and functions which turn into our epics and break down further into stories –here’s what we need to have in order to create the software for this particular process.   

Cornelius:   So, it’s basically just a matter of starting somewhere and just breaking it down, breaking it down and continuing and not stopping until you’re done. How do you know you’re done?

Betsy:   Well, you’re done when everybody says, “Yes, this is good enough”.

Cornelius:   We’ve run out of bagels we have to…

Betsy:  [laughs] We’ve run out of bagels, we’ve run out of time or everybody gets dispersed to another project because it’s good enough. We’re never actually fully done but as long as we feel like we’re good enough. That’s when we’re done.

Cornelius:   And I think “we’re never fully done” is underlined by the fact that the next step—big step is elaborate.    

Betsy:   Yes

Cornelius:   What do we do now? Now that we have this initial list of the user stories?

Betsy:   Right, so elaborate really kind of goes into understanding it even a bit more and we even start going in and having some design sessions. Because I know especially with our stakeholders, they have a vision in their head on what this thing looks like and what it’s going to do. The sooner I pull that out of them and understand where they’re coming from, the better.

So, it’s really going through and saying, “Alright, well let’s talk about this process. Let’s dive a little bit deeper. Let’s go into the next layer and understand it a little bit more. What do you think this users’ screen might look like? Let’s talk about the different ways that we might be able to solve this problem”.

And it may not always be software related. It could be a process thing that we just need to change. And so –that’s even better that we don’t have to build with anything if we make some tweaks in our processes, let’s do it that way. So, it’s really kind of going through and really peeling that onion –it’s that next layer.

Cornelius:   OK. So, in the last 5-6 minutes, we’ve talked about writing user stories but your presentation title: “Not your Mama’s Acceptance Criteria”—when do the acceptance criteria start coming to play?

Betsy:   That’s in the Refine phase.    

Cornelius:   Ahh. We’re not there yet.

Betsy:   Not quite.

Cornelius:   OK, so we’re still developing these user stories. Under Elaborate you also have create mock-ups.

Betsy:   Yes. That’s the what the whole system might look like—the screen mock-ups. So, let’s start putting different options out there and so it’s really kind of thinking through – “Well gosh, do we need to have this all on one screen or is this a flow and a work-flow that we need to have here?”

So, you know there’s different ways that we can always solve things. It’s looking at the various options that are available and then choosing one direction that we think is going to be best for that user community.           

Cornelius:   OK. And then lastly under Elaborate, elicit story point estimates. How do you like to elicit them?

Above are the first few pages of the transcript. The complete PDF transcript is available to Premium subscribers only.