Using Cynefin to Prioritize and Analyze Features, User Stories, and Requirements

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 • 47,711 students

Lecture description

Cynefin is a concrete, simple yet powerful weapon in your arsenal identifying and dealing with IT project issues. It has proven to be effective in many different settings. You will find it useful in determining which projects are more likely to succeed before you spend a ton of resources. It is also a valuable tool for assessing and prioritizing individual Features, User Stories, and literally any form of expressing a business need.

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] Know I'm going to introduce you to a fairly new concept actually this is called a framework. It's called the Konev and framework. We're going to see the spelling and a few minutes that is a way of dealing with uncertainty. It's a phenomenal new idea in dealing with uncertainty and uncertainty abounds. A certain Jesus everywhere. If you started a new project there is uncertainty. If you're actually a developer and you're supposed to be writing a user story that you just got you have uncertainty according to this framework. Anytime you're faced with a new situation you're facing with disorder. Disorder is not bad. It just means that you have not yet had time to analyze the uncertainty in the situation and therefore it is an ordered or disordered. If I analyze the situation and I start to recognize what level of uncertainty I have the first thing I'm going to find is I'm going to find some things that are not at all or very very minimal uncertainty. That is to say the situation. The problem I'm trying to solve is obvious it's a simple situation. Simplicity usually means I have done this before. I know what I'm doing. I've been down that road. Yeah I know what to do. All I have to do is pick the best practice that I have developed or that I know and use and apply it implement it. I'm going to address any problem that I identify as being in the obvious or the simple domain as being an obvious as being a simple problem and just solve it. That's a good thing. Obviously if I know what I'm doing I'm doing it by being productive. Unfortunately not everything is as simple as it seems. If I'm looking at a situation and there are some things in the situation that are complicated by definition complicated in Konev and means it is something that I know what questions I would need to ask but I don't know the answers. I it's something I've never done before and what I say I by the way my team my project team has never done this before but we're uncertain as to what what who should we ask what should we believe. What I know what questions to ask but I don't know who to believe. When I ask these questions what's going to happen if I'm in a complicated domain is I ask a bunch of experts can I get a bunch of different answers. They're the experts typically do not agree that this is the best way to approach it. But I'm going to end up doing is I'm going to listen to the experts and then I'm going to form my own opinion based on their knowledge and I'm going to evolve what's called the best I choose me a good practice not a best practice that's going to come up come later on once I have done this several times I've done it 50 hundred times then I can develop or evolve the best practice right now. I've found ways that work and we're going to call that a good practice. It's something that I've gotten from the experts as long as I'm dealing with this side of the equation I'm dealing with problems that are obvious or complicated. I'm in a domain where business analysis or all of the analysis techniques of looking at problems looking at requirements interviewing people having conversations and so on are very effective. Where they start to fall apart is if life gets even more complex that is to say beyond complicated it's what the domain of what it calls complex and complex domain. I don't know what questions to ask. I don't know what answers to believe. I don't know who to talk to. There's a whole lot I don't know. I'm in a situation in which I am very insecure. There's a lot of uncertainty in this situation. And what I what the only thing I can really do at this point is try to find a way of moving out of the complex domain into complicated and or obvious and the way I do that is by developing what we call safe to fail tests. Now by definition a safe to fail test is something that I can do that will help me understand the situation. It will clarify something and I can get at least part of the problem that I'm facing over into a less complex meaning either complicated or obvious to me. However whatever tests I come up with can't make the situation worse that's what we mean with safe to fail. If I execute the test I try something out and I learn something out of that and I immediately can move it over into the other domain. As long as I'm in the obvious domain I'm chugging away I'm working on getting the job done if I'm in the complicated domain and figuring out what I need to do so that I can get chugging along again and get it down into that obvious domain. If it's in a complex area I have to find out ways of moving out of it just taking these three concepts complex complicated and obvious just those three domains a funny thing happens if I start a new project Typically people will look at a new project and they're going to start to do what they know how to do. Meaning they're going to try to get a solutions for all of the obvious things simple things because that's most people's comfort zone. We'd like to know what we're doing. We'd like to be confident in what we're doing. And so I'm just executing I'm fine following my best practices if I am on a project and it turns out that there is something that is complicated about the project it's going to hold me up I'm going to be doing my simple things as long as I can. And then I run into the complicated things and it's going to take time to get those resolved and the resolution of those can make what I did when I was thinking it was a simple situation incorrectly can cause me to have to redo things because I didn't know that. So now I'm going to have to change what I did. If you're dealing with a project that has complex dimensions to it then it's even worse because what you all of your work might have been wasted unless you can find a way to resolve the complex components of that situation of that problem that uses story that requirement whatever it is you're dealing with. I'd recommend taking a different approach if you're going to use this and as a thinking tool when you start a project don't start by doing the things that are obvious that are simple. Start by trying to figure out what are the things that are really complex. What are the things that we don't know how to do yet. What are the things that we're going to really have to learn something totally new in order to try to achieve it. And if I identify that there are things on this particular project that we have never done before. And we don't know of anybody that has done them let's address them first because if I can solve the complex problems then the complicated and the obvious are going to become legwork. If I however spend all of my time and money doing the obvious and the complicated things and then I run up against the complex. And I can't find a solution. My product is going to fail and that by the way is what happens on quite a few I.T. projects we get done with what works. What's obvious we're actually wasting our efforts if we can't solve the complex problem. We actually apply this technique on a recent project in our company and the results were amazing. We typically we would have started the project would have been chugging on thinking we're making great progress. Yeah there's a couple of things out there will have to do with them later but because we took that complex area first and we started looking at that and recognize that you know the idea that we were working on that was going to be so simple that we could just start delivering it wasn't actually going to solve the problem at all. There were areas that were that were complex that we had no idea how we were going to solve them. So we decided OK let's not start the project right away. Let's get let's address these complex areas first. And right now that product is still on hold because we haven't found a solution yet for the complex area complex complicated and obvious domains in Konev and are areas that we have a strategy for. And then life gets chaotic if you're in a chaotic situation you're facing a cloud a problem. You basically are in a situation where you're lost you've never been there before. You have no idea what's going on you don't know what to do to solve the problem. You just know there's a huge problem and you've got to do something. If he has if it's a you're talking about this from an I.T. or an organizational perspective typical example of a chaotic problem would be your production system has just crashed and you can't get it started again. If you don't get it started within a couple of weeks your entire company is going to go bankrupt. That would be a county problem. That is you don't know why it crashed. You don't know what caused it you don't know where to start. If you're dealing with a chaotic situation according to the Konev and framework what you want to do is anything you can think of that might alleviate the situation stop the bleeding do something anything to try to move the to try to try to calm the situation so that you can start to think about. Safe to fail if you're in chaos. You don't have time to do analysis. You don't have time to even think about how can I prove what the situation is. You have to react. Or bad bad things will happen. Now that is those are the four domains of the Konev and framework. Personally I think that this is one of the greatest tools that we have invented for dealing with I.T. projects in recent history. Obviously Konev is not an I.T. tool. It has a lot of applications in a lot of areas and the example I was giving you earlier wasn't even an I.T. project. It was a project that we were doing for a customer to develop a video. Ultimately you can use Konev and in almost every walk of life I think personally it's such a powerful tool that I want to give you some time to think about how can you react or how could you apply to the your environment. Now we're talking here about the environment of defining requirements or getting an understanding of what the business needs and wants. How could you what could you do if you are in a project and you recognize that you are in the complex domain in the complicated domain what tools or techniques are you familiar with that you could use to try to get this thing moved into a less complex domain. Either from chaotic to complex complex to complicated complicated obvious we're trying to get everything into the simple or obvious domain so that we know what we're doing so we can actually get the job done when to give you a little time to think about that and a little exercise and then I'll give you some information about how I see that or are we here in our company look at using Konev and to figure out what to do in business analysis or in requirements analysis.