Reviewing the Backlog

• Kelly: So Pete, we are pretty much done with our Agile Planning, and are nearly ready to start development. All we need to do now is write acceptance criteria for our stories, and we can start coding.
• Pete: "all we need to do" as if that's going to be a small thing?
• Kelly: Oh yeah and order the backlog...
• Pete: Come on, I thought you said we were done?

Ordering the Backlog

• Kelly: Well we are almost done, first let's order the backlog in terms of technical and business priority. Remember, we are going to focus first on the simple act of viewing a movie, then worry about authentication and sign up.
• Pete: Why backwards like that?
• Kelly: Because we want to do the highest risk or most differentiated, and even, the most simple things first, because that is our bread-and-butter. Anyone can build a login, but if we build the movie watching part first, not only could we show it off to people for feedback, but then we have something that we can build off of.
• Pete: Ok yeah, like the "seed," and also I see what you are saying, because the concept of "movies" is just a single item, versus having to worry about types of users.
• Kelly: Exactly, ok here is the top of our re-ordered backlog:

• Kelly: So we'll start with a simple movie watching page, then add some way for existing users to log in and out, which will let us restrict public versus internal movie pages, and finally add some sign up ability. The rest of the stories are further down the backlog.
• Pete: Ok cool, so you were saying earlier, that we might add in the other stories, from other scenarios, before getting to the ones at the bottom of this backlog?
• Kelly: Yes, exactly, like it might make business sense for us to make the admin page, so someone can add lots of movies, which make all the public pages, way before we even let people sign up, to create buzz.
• Pete: Ahhhh, I see what's going on here. So we are actually going to release some of this to the public, so I guess I see why the priority order can matter.
• Kelly: That's right Pete, this is Agile, we try to release things in chunks that make sense to the user, and let us be flexible with our business.

Adding Acceptance Criteria

Now that the team has an ordered and well defined backlog they can move right into the acceptance criteria definition, which could happen in-line with development planning. The two are so closely linked because eventually, these acceptance criteria could for the drivers for automated tests that ensure the application is built correctly.

We won't detail the acceptance tests for every story here, but our team will tackle the first story.

• Pete: Ok and what's this all about acceptance criteria.
• Kelly: Well let's say we start development of the first story?
• Pete: Are you serious?
• Kelly: I mean, let's just say; how do we know it's finished?
• Pete: Well when a user can watch a movie? Right?
• Kelly: Yeah, and that is an acceptance criteria, albeit a rather general one. We just want to specify, very explicitly, what criteria can be used, by anyone, to accept the story as complete. This will help in writing tests for the story, and sharing knowledge with other developers.
• Pete: How detailed should I have been?
• Kelly: Fairly detailed, we should write out every thing that needs to be developed for the story to be correct, and here again is where we add more layers of detail, for example:

I can access a movie page by a public URL
I will see the title of the movie
I will see a basic description of the movie
I will see a video player on the screen
I can play and pause the movie

The movie page will adapt to my device view port
The movie page will work correctly on modern browsers

• Kelly: See?
• Pete: Oh yeah, wow, I could start coding that up right now. The first several make sense, but what's with those last two?
• Kelly: Well they are acceptance criteria, we want this to work on mobile or desktop and on the major browsers.
• Pete: Oh, I figured I'd just use Chrome to develop with.
• Kelly: That might work for a little while, but this is the idea, we have to decide what our business requirements are, and how those translate into acceptance criteria. Don't we want everyone to be able to use our app?
• Pete: Ah true, we do. So now can I finally start coding?
• Kelly: Sure Pete, let's get started, and I think you will find that with these basic planning techniques we'll build some really good and useful software.
• Pete: Awesome, I know we will!