This is a follow-up video to the article that was published last year with the same name.
In this video I talk about the appropriate time to produce user stories, and how user stories alone are often not enough.
LEARN.BA. In this video I want to talk about user stories.
So last year I published an article on the blog I learned IPA that was called User stories are not requirements in that article created a little bit of friction some of the feedback and some of the comments that I received on that article touches on a point that I covered in the last video which is the theme of using the right tool for the job. Now some of the comments that I received were really aimed at trying to convince me that yes user stories are good and you should use them and I don’t think that the people that sent me those comments really understood the point of the article because the point of the article is not that you should never use user stories. The point is use the right tool for the job and the job means that no one. What kind of a requirement are you documenting. Number two what kind of an environment do you work in. Because both of those factor into the different types of tools that you want to be able to use. So I want to give you a few pointers on when you should and should not use user stories as a way of documenting your requirements. But first a little bit more about what was on the article in the article. I basically covered a few different points. Number one was that user stories are a very high level of detail right. They don’t go into the level of depth that you may need in a lot of circumstances in your requirements and so the level of detail for user stories is usually not very high in most different versions of use user stories that you do. Number two is that you always have to consider the developers perspective when you’re trying to figure out how to document a requirement. Remember what I said in the last video. Your business requirements you have to start to view them as kind of a contract between the business side of your company and theI.T. side of your company. So you can’t afford to ignore theI.T. side. The developers that are building on the requirements that you write are. Part of your audience for your requirements and you hot you cannot afford to skip their point of view when you’re writing requirements. And that’s why user stories don’t always really fit the bill. That’s part of the reason it’s because the level of detail in user stories isn’t isn’t always up to snuff when it comes to the development portion of the project.
The third thing I covered in the article was that there are five really key questions that you should always try to address. There are five key questions that you should always try to address when you’re thinking about documenting requirements or when you’re trying to figure out what tool you should be using to document your requirements and I’m not going to cover the five points here but the article is very clearly lays out the five different things that you should consider and there are more things. But those are really the five core things you should read those five things because it alludes to something I talked about in the last video which is there are different types of requirements and each of those different five points that I talk about in the article starts to lead you down the path of understanding what the different types of requirements are. So Gordon read that and use that as your starting point for understanding what the different types of requirements are. So let’s talk about user stories a little bit more so in the article I said user stories are not requirements. The purpose of that statement is to say that if you’re solely writing user stories you may not necessarily be doing your job in producing requirements because in many instances user stories are just the starting point.
They’re just the starting point for documenting a certain type of requirement. And so in in many instances just writing user stories is going to be grossly inadequate for you to be able to communicate your requirements in a comprehensive way. OK now what. When can you use user stories and rely. Almost solely on user stories. Okay. There are a couple of instances where you can do that. Number one. Is that you are in a very well orchestrated agile environment. OK.
And that the well orchestrated part of that is very important because a lot of organizations will say that they’re running agile but very few organizations actually do agile the way that it’s meant to be operated. So if you’re working for a company that says that they are operating in an agile way there are certain things that you should look for to make sure that that’s actually happening. But if you’re running in a purely agile environment that’s when user stories become very important because there are certain things that are done in Agile environments that make it very conducive to user stories because if you write user stories in an Agile environment you don’t run the risk of creating on clarity in your requirements. OK. So the first place where you can use user stories and not really provide a whole lot else is in Agile environments OK the second instance where you can use user stories is if you’re working with a development team who has very good knowledge of the systems that they’re working on and just as importantly they have very good knowledge of the business environment. Right. And so when you’re working with developers like that on your project you don’t necessarily always have to elaborate down to a level of like an excruciating level of detail because if you have a developer who’s been let’s say working in finance systems for the last 20 years and they’ve been working at the same company for the last 20 years chances are that that person knows inside out how the system works and they have a very good idea of how finance systems in general work in those types of instances you don’t have to spell out a lot of the stuff that they already know. Right. And that’s why in those instances you can start to write user stories because in the user store you’re basically saying the user wants to do this and here’s the outcome that I’m looking for out of that. Out of that user interaction. Right. The developer who has the 20 years of experience working in finance systems sees that user story and they almost automatically understand a lot of the different business rules and they’ll usually know the answers to a lot of the questions that they that a typical developer would come up with. So you’re working with a developer who understands things very very well. You can get away with writing user stories. The third instance is if you or your project is in a huge time crunch. OK. And this is very important because you can’t do this on your own. Your project is in a huge time crunch and you don’t have the time or the resources necessary to write more detailed requirements in that case. You can get away with writing user stories as long as your organization or your project accepts the risks of writing user stories. OK. So this is a situation where you might be under traditional waterfall project but your project manager or the project sponsor says that you don’t have let’s say eight months to do this project which is what you actually need. You have four months in that situation what you need to do is you need to start cutting a lot of corners. And one of the corners that sometimes you might want to cut is to a vote or avoid a lot of the detail in your requirements but you as an analyst cannot make that judgment call on your own. Because if the expectation that your project or your sponsor or the user group that you’re working with if the expectation that they have is that you are going to be producing detailed requirements but you go off on your own and you produce just user stories. Is going to be a huge disconnect there because that introduces risk into the project that the project manager doesn’t know about and that the rest of the folks that are involved in your project don’t know about. So if you’re in the third situation where there’s a time crunch you have to produce detailed requirements but you just don’t have the time and resources. You have to make sure that your project your Project Manager and the other people that are involved your other stakeholders are aware of the fact and they not just aware but they accept the fact that part of the requirements process is going to be introducing some risk into the project because of the fact that you have to take shortcuts. You cannot do that in a vacuum you cannot do that on your own because that can create a lot of downstream problems for the project. OK. Everybody needs to be on the same page. So the real key takeaway here for this video is is I’m going to reiterate I want to reiterate something I talked about in the last video. You cannot be dogmatic you cannot be dogmatic about certain tools certain types of methodologies ways of doing things you cannot say to yourself as a good analyst if you want to be a good analyst you cannot say here’s the way I do business analysis and I don’t care how the rest of the world functions. This is the way am. I’m choosing to do it. You cannot afford to operate that way because that level of rigidity if you’re overly dogmatic and you’re saying that I’m going to use it use case or I’m going to write a user story despite what kind of requirements there are.
You’re not you’re not going to be up to the level of being competence that you may want to be. So the lesson that I want you to walk away from is there is a lot of variability in situations that you’re going to deal with and you have to learn how to use the right tool for the job use cases are good for detailing the user interaction which I talked about in the last video user Tories are good in the three instances that I talked about. So you’re in a well orchestrated agile environment. Number two is that your developers are very well educated about the systems and especially about the business side of things.
And the third one is is that your project collectively has accepted the risks of you not writing the full details that the development team needs. Those are the three instances where you would use user starts if you are interested in learning more about business analysis I would recommend that you check out the blog on our Web site at learnedB.A. the very specifically you should go over there and read that article that I published last year called User stories are not requirements and feel free to leave your thoughts on what’s in that article because you may or may not agree.
But if you disagree I’d like to hear about it so that I can address some of the questions or some of the objections that that you may have. OK so go over there and check out the blog and I’ll see you in the next video.