In our last video, we looked at the first section of scope and limitations, which were our major features and talked about how that's really the meat of the document for us as big as that's the most important area for us, because we know we're going to be building our requirements around those features. Now we're going to take a look at our next section, which is section two dot two. And that is the scope of initial and subsequent releases. So in this section, there are a few different ways that this can be documented. So I have an example here. And then I'm going to talk about a couple of other ways that this can be documented.

If you recall, in the first video for this course, I talked about how there is not any one way to do documentation or to do the different tasks that a BA does. And this is one of those points. So to me I think it's great to have the flexibility and be able to document things in different ways that work for different project teams. What we're doing in this section is allowing the stakeholder to tell us what they feel is things that absolutely have to be included in the first release, and things that can wait until a later release if there are things that we just can't get done in the first release. So this gives them that opportunity to tell us ahead of time, if something's going to be more complex and require that we spend more time on it, then it's okay if this gets done at a later date, but it's not okay if this gets done at a later date.

So it's telling you what has to be now and what can be later. So taking a look at what we know we're doing for this project. We have a couple of different things here in our scope of initial and subsequent releases section, we have three columns feature we have now, which is release one, and we have later. So we're not saying if it's released to release three, release four, we're just saying it's not now it's labeled. So this can be, like I said, documented in a few different ways. And this is my first example for you.

So my first example really lays out what are the kind of high level features that have to be included now versus later. So when you look at a feature of site updates, we're saying that complete site update functionality except to scheduling and reverting has to be included in release one. And what that means is that feature four, and feature six can be done later, because those are the things related to scheduling. Link changes and also reverting changes to a previous version. So what the stakeholder is telling you is, they must be able to update the site, which should be obvious. But again, we want things spelled out whether they're obvious or not.

So all site updates have to be able to be done as part of our initial launch of this project. Except for these two, these two could come at a later time. If they have to, then we also have full site launch with all remaining features. So what they're saying with this as that mp4 and Effie six is the only features that could come at a later date, and that all of the remaining features have to come with release one for the North America region. And then other regions will follow that initial launch. And again, we'll have all of the features except possibly Effie for an Effie Six.

So this is one way of documenting what comes now versus what comes later. Another way that I have seen this done is to list out all of the features here so your section can grow. If you have 50 features, you would have 50 line items. So you would have SC one in this first section, and you would say, release one here. And then maybe you would have fv four here, and you might say, I have nothing here because it's not going to be in release one. And you would say release two here, like I want this by release two, so you're not just saying later, but you're saying how much later like it can't be released three or release four, it has to be released too.

And then the same thing with mp3 mp4, five, six and so on, you would state whether each of those features are released one or if they're later which release they should be included in So alternatively to that we have a third way that we can do it. And that's really by having features be bulked together. So rather than having an individual line here for each one, you might say SC one through three, and those are going to be released one, fv, four and six are released two, so on and so forth. You can kind of bulk things together, whether they're in order or not. So you could say f e one through F e three, or you could say f e one comma f e three comma f e seven, so they don't have to be together in the features list. And by the way, your features list isn't going to be in order either.

So that's a few different ways of being able to document that and you can guide the stakeholder on how you think it should be documented, or you can let them choose which option That they like to use. In any case, at the end of the day you just need to have an understanding of what features are they expecting now versus what features are they expecting later