Analysis in Lean and Agile Environments

Tom and Angela Hathaway
A free video tutorial from Tom and Angela Hathaway
BA-EXPERTS: Business Analysis for Anyone Wearing the BA Hat
4.3 instructor rating • 12 courses • 41,080 students

Lecture description

When do you perform critical business analysis activities in Lean and Agile approaches and what level of detail do the activities need to achieve?

Learn more from the full course

Agile Business Analysis: Getting / Writing Lean Requirements

Business Analysis Techniques for Discovering Requirements, User Stories, Features, and Gherkin (Given-When-Then) Tests

04:36:58 of on-demand video • Updated October 2019

  • Define the capabilities and challenges of Lean and Agile software development philosophies
  • Adapt 10 different requirements gathering (elicitation) techniques to Lean, Agile, and Continuous Delivery software development environments
  • Support Lean or Agile teams by expressing business needs and wants in formats that optimally support all modern Software Development Methodologies (SDM)
  • Reduce the time wasted on miscommunication between stakeholders of IT projects by recognizing and removing terms and phrases that can be easily misinterpreted
  • Drill-down into requirements, features, user stories, and functions to identify and express test scenarios in Given-When-Then statements to facilitate automated testing
  • Identify 17 types of Non-Functional Requirements (NFR) and develop Given-When-Then (GWT) test scenarios for them
  • Leverage the learning curve to incorporate the presented techniques into your job
English [Auto] OK so our topic is trying to figure out what the business community needs and wants from I.T. in that context we usually follow the philosophy that's called business analysis meaning trying to find ways of ensuring that we know what the business community needs and wants before we start to develop it. Agile has made some very major inroads into that and in this particular instance we're going to be talking about the scrum implementation or the scrum methodology of Agile that is the most commonly used methodology for agile projects. At the beginning of a project you need to have some guidance some idea as to what you're trying to achieve. I actually have to be careful with my terminology because the word project is not really an agile idea. They talk about the product product. Here's the end result of doing work and Gyles goal is to deliver a prop a product that the user community the business community can use and that is sufficient to meet their needs. It's not necessarily going to be perfect and we're not going to keep tweaking it forever. We're going to we're going to deliver a an application or in this case an application that meets the business need as well as we can to get started. We need some kind of a document or something to start with and the early phases usually there's a thing called a vision statement which is a very common document or a very common way of expressing what an A and agile initiative is going to try to achieve. Vision statement basically is an expression of what the business community will have when the product is in installed is as complete as it's going to get in order to get started with an agile project. First off we need a thing called a product backlog now the product backlog and agile is really a collection of things that have to get done on the product in order to be able to achieve the vision and or get the vision statement that goes with the vision statement says in the early part of the project we we're basically starting off by identifying features users stories things called epix which are really complicated or maybe even complex user stories that we have to break down into more detail using stories that the developers can actually work with. But really doing is called seeding the product backlog and you're going to have a collection of things that is going to actually grow. It's going to be very flexible it's going to be volatile over the course of the project. So at the beginning you put a bunch of things into the product backlog and you can get started. The idea of a scrum approach to developing the technology is broken into First off releases and a release in the scrum terminology is really a segment of time typically a three to six month window. And it's always a fixed segment of time in which we are going to deliver working software or working application to the end user community. The key thing is it is something that is going to go into production within that three to six month timeframe. And so in the Agile world what we need to do is a thing called released planning release planning is all about looking at the product backlog which is maintained by an individual called the product owner who is responsible for the business side of the project and the agile team consisting of developers testers are going to work with the product owner to extract out of that product backlog those things that they feel they can get done in that 3 to 6 month timeframe. Actually the driving force is the product owner who says these are the things that I would really like to have and the agile team looks at those and decides can they deliver on that or not. You're extracting out of the product backlog uses stories epix features these kind of things and you're breaking them apart in the release planning to figure out okay what what what are we going to achieve. How complex are these things. How are we going to prove when we're done that they really work so what's our test strategy. What are the work items or the tasks that we have to do in order to get that job in order to to implement that particular user story or that particular feature. And so you get a bunch of things that go into the release backlog release backlog is going to be worked with by the agile team and the product owner in what are called Sprint a sprint and the scrum methodology is a section or a two to four week window of time in which the sprint the agile team excuse me will deliver working software. This is not necessarily going to go into production. It is software that has been tested it is software that works but it's not necessarily going to go out to the end users until the next release or Sprint delivers working software release delivers production ready software and the idea and the Sprint is you're looking at the release backlog and you're figuring out whether the things that we can get done in this sprint you picking out specific user stories now you're going to take those user story as a developer. The idea is the users story tells you what the end user wants. I'm going to now talk to the end user talk to the author of the user's story to make sure that I have a clear understanding of what they really really want. Now that I'm getting ready to immediately start coding it one way of doing that is have a conversation between the developer and the end user. And we're going to identify how is the end user going to test or prove when I deliver the software that it works we're going to develop test scenarios. So you have a test strategy coming out of the release planning now we're going to develop test scenarios situations and as mentioned earlier that are going to be used to prove whether or not the application does what we think it should do. And now we've gotten a better idea that we have a we're ready to do a sprint or to start the Sprint and during the course of the Sprint we're going to have ongoing conversations between developers and the product owner or the author of the of the user's story. And these may quite often and in the meantime actually involve a person who has the title of business analyst who is waiting to be at that is not a member of the agile team but is what is called the customer side team which is somebody that is out there helping the business community making sure that what the agile team is delivering is correctly understood and is that the business community knows what theyre going to get when that when the development is done. So you have these ongoing this ongoing work that is being done to develop the software. And you had these daily scrums which are meetings that are every morning the agile team starts off with a daily scrum which gives you about 15 minutes for every member of the team to report what they did yesterday. What kind of impediments they had and in agile terminology and impediment is anything that keeps the developer from getting the job done doing what they thought they could get done in a certain time frame. Impediments are given to the product owner to get resolved and if there is no instant resolution then the developers are going to do something else until that impediment becomes removed and then they can come back to work on that piece of the application that uses or whatever else it is. And now during the scrums the daily planning and during the conversations they are basically the whole team is basically looking at the of stories and developing given when then or tests and test cases which are at a level of detail where I know what data is going to be used I know exactly how we're going to prove that this particular user story this particular feature or whatever else is implemented. That's the whole concept behind the timing of that doing the analysis in an agile world. Historically and in a waterfall world we talked about strategic business analysis which was the up front work the very beginning of the project to decide if you wanted to do a project or not. Well guess what the agile or lean that's still there you still have to have something upfront to figure out do we even want to do something or are we going to expend any resources on trying to solve this particular problem. And then you have what is called Tactical business analysis that's during realist planning and Sprint planning where you're really taking it down to a lower level of detail now that the decision has been made. Let's make sure that we know where we're going. But we have a good idea of where we're going. And then you get into the conversations where you're going to do what is called operational business analysis which is getting down to a firm understanding of what the business community really really needs and wants and what their user story actually says at a lean approach. There are two concepts although they apply also there's bleed through here over into the agile world. It's a bloody mess. Come to think of it actually just in time and just in case work lean because lean is not just focused on software it is about building anything. The key concept behind lean is let's not waste our time and money and energy doing things that are later ongoing to prove to be unnecessary or totally useless. Let's not do things too early because as the world changes they may turn out to be irrelevant just in time work means. I'm going to do things immediately before I need the output. While in the manufacturing world just in time means I'm going to produce a part when somebody needs that part to put it into a bigger part into a construction or something like that. I'm not going to build a block until somebody is building a house that's just in time concept. Because the work that is downstream of building the house they might need more than one block. If they were if they had to wait every time on a block we've built it and then they could put it in there. They would be wasting their time. The twin concepts of just in time just in case just in case says I'm going to have a high enough work ahead that they don't have to wait that they're going to be able to do their job. And just in case actually it does possibly entail some wasted effort because I might think I have to do that. But as their work progresses it turns out I was wrong. I analyze the use a story that uses story has been tossed out. How that can happen but it's going to be minimized as opposed to my trying what we can waterfall tried to do of getting all of the requirements up front perfect before we ever started to write a line of code. Now the idea is we're going to get we're going to stay at least one sprint ahead of the developers with our understanding of the what the requirements are with our understanding of the uses stories of the EPIX and so on. But we're not going to analyze every uses for it we've got to the nth degree just in case they ever need it. We're only going to do the things that are going to be happening within the next sprint to make sure that we're not wasting our time in the world of lean just like an agile we have to listen and clarify vision statements we have to here use our communication and elicitation techniques in order to do that. We have to make sure that we are getting the right understanding of the vision statement and the features and actually talk a lot about we understand the same thing. Actually two people can understand the same thing and mean something very different or still be very or miles apart in what they think they understand what we're really looking for is a common or shared understanding of a situation. I have a vision statement from a senior manager. I have to make sure that I understand their intent and not just the words we're talking about in a release planning and in the sprint planning. Are we going to need communication solicitation techniques in order to ensure that we understand the users stories we understand that the features that are part of the user's stories are what has to be done. We understand the general. I have a very good idea of the solution level requirements or the functions and nonfunctional things that we're getting to and that gets even higher. And when we get down into the daily scrum or into the one on one conversations between subject matter experts are product owner and the developers we are going to need these levels of understanding across the entire spectrum for the entire project whether we're doing lean or doing agile. By the way doesn't really matter. The concept of not wasting time of not trying to do something that's impossible of recognizing complexities and dealing with the complexities in the most efficient manner. That's what makes delivering software lean agile and actually getting the customer what they need and want in a timely manner.