 Hey, everyone. Actually, first, before we start tonight's session, we've had some incredible volunteers helping us out for each of these sessions. The guys from engineers.sg. And they film all of these and make them available on the internet. So I think we should give those guys a round of applause for that. Tonight, Michael from Singapore Power is helping us out. So these guys do this. This is like a hobby for them, which is pretty cool. Helps us all out. So today, we're going to be going to Scrum Foundation's part three in our Level Up series. We're going to be talking about effective sprint planning. But like all the session we've done so far, I'll do a short recap to hit some high points, to hit things I think that are relevant to tonight's session. And heck, it doesn't hurt to remind ourselves of this stuff. So just really quick, our quick recap. So first off is there's three things we need to think about when we think about Scrum. First, we need to think about process. Next, we need to think about roles. And third, we need to think about the artifacts. Now tonight, we're going to be touching on product backlog and sprint backlog are two of the things that we'll really be touching on. So we'll make sure that those will get brought out. Now, you're going to hear this from me again and again, because this is the foundation of Scrum. The fact that it is an empirical process, not a defined process, that is a process that is built at its core around you having transparency or visibility into the process, what's going on. Think sprint backlog, think product backlog, think burn down charts, think all that kind of stuff. And that you're inspecting the state regularly. Think your daily Scrum or stand up. Think your sprint review, think your sprint retrospective. Think even your sprint planning meeting. These are all involved in the process of inspection. And based on that, you have to do that inspection frequently. And as I stress, this is why you don't decide you're not going to have stand-ups. This is why you don't decide, oh, we only need to have stand-up once a week. We only need to have it twice a week, because you have to inspect frequently. And then you adapt based on that. I have seen too many teams who have decided, oh, yeah. Well, they say we can adapt Scrum to our needs. So we're going to only do stand-up once a week. Or not everybody has to come to stand-up, those kind of things. That's the thing that you need to understand. Inspect, adapt, empirical process. This is the foundation of the empirical process. And I'm just going to keep hammering it on you, because if you understand this, you can rebuild Scrum yourself. OK? This is for principles. From these first principles, you can derive the rest of the theory of the process. Now, how do we apply this? Well, we have the sprint cycle. And the sprint cycle, as I said, we've got sprint planning. We've got the sprint itself. We've got sprint review. We have retrospective. We have the daily Scrum. This is the sprint cycle. And you basically can say, how long is our sprint? Is it two weeks? Is it four weeks? Is it one week? You can adapt that. Now, next week, we'll actually talk about some advanced topics. And one of the things we'll talk about is Kanban. And Kanban is an empirical process. But it likes Scrum, has many of the same features as Scrum, but is a different process. And one that's more suited to teams that are involved in responding to production instances, customer requests, things like that, while still having a product backlog and working towards the delivery of the customer value in that backlog. And for tonight, what are we going to talk about? We're going to talk about sprint planning part of the sprint cycle. So that's where we're going to focus our attention today. We're going to talk about that. And we're going to talk about how do you do that most effectively. So any questions before we jump into things? Again, throughout the process, ask questions. I know that that's counter-cultural, but let's do it. If not, I'll just start calling on people. Daniels and Albert have been here enough. I just might just say, what do you say, Daniel? What do you say, Albert? Because you've been here every time. So you could be victims. OK, let's go in. So covered this last week, but let's just hit it again. What is a sprint? A sprint is a time box period of development where you deliver a potentially shippable product. So one of the things you have to make a distinction between in your mind is done versus shipped. Done is not necessarily shipped, but can it be shipped? It's probably a condition of being done. Because there are reasons why you may not ship. It may be that product wants to get enough value together to get the consumers in the field to consume it. Because there may be a cost, a switching cost. And so there's got to be enough value to make that switching cost worthwhile. Or it's just, hey, press cycles, they know that technician will only cover them every six weeks. So they want to make sure that they're delivering value every six weeks. It might be that they want, hey, we're going to have a board meeting. We want to have something to make them all happy at the board meeting. These are all reasons why you might not ship, but you're going to be done. You're going to be completed. Another way of taking this is deployed versus shipped. Is it deployed? Could it potentially be turned on versus shipped? Sprint planning is just the process of defining the scope of the sprint. It's really saying, what will we do? How will we do it? Now, these are owned by different people. What will we do? Well, that is owned by our product manager. How we will do it, that's owned by the product team. We talked about those roles and those distinctions of the roles last time. What will we do? How will we do it? That's really the questions you're asking. So what's the first step of that process? Well, the first step in that is backlog conversion. Good product owners, good product managers, are maintaining a product backlog. Now, that product backlog starts from the stuff that's most important, the stuff that you want to ship, and get out to the least important. In addition, your process of definition, your level of definition is going to go from highly defined to, well, it's kind of gleaming my eye. Now, what happens is there's a process of taking the tip of this list, the tip of this list, and moving it over into a sprint backlog. Taking the product backlog, the top of it, and moving that over into a sprint backlog. That is the essence of sprint planning. Is this process of taking your tip here and converting it into a sprint backlog? Now, how do we do that? Well, first, the product owner is going to tell you in the sprint planning process what I want, what I need here. And they're going to start with the first thing. Now, this isn't a detailed explanation of it. This doesn't mean that they're developing this on the fly. God help, no, they're not writing the story on the fly. They're not writing the acceptance criteria on the fly. We'll talk about that process and how you get that there. But it's them really kind of presenting it to you. They're making the elevator pitch to you. Now, as a team, they're laying the context. They're explaining the customer value. What I need, what I want here, that's what they're giving you. And they start at the top. And they do the first story or the first task. And the team looks at that and goes, how will we do this? What is the complexity here? And they say, yeah, we got an idea for how to do this. We've got a feel for the complexity. And given everything else we've committed to, we can add this to the list. And you iterate. So first, your product manager lays out an overall vision of what this is. And remember we talked about the sprint goal last week? There's a sprint goal that we're going to have. It's tied to your stories. And then he's going to say, or she's going to say, here, this story here, this one, this is the most important thing to me. This is the most important thing to our customers. And the team goes, mm, how will we do this? Mm, what is the complexity here? Do we think we can do this with everything else we've done? OK, cool. Add it to the list. And you iterate through. And so you go, and you start from a product backlog. And you go, this story, yeah, we can do it. Add it to the backlog. That's right, yeah, we can do that. Move it over. Task, mm, yeah, we can do that. Story, mm. Now what may happen as you're going down this list, the team may say, oh, that is too much. That will throw us over. So we're going to go and grab this story, what we can do, which means that your product manager on the fly has to say, oh, is this the delivery of the value? Is this critical catalyzing value? Because sometimes that's the case. Mm, well, maybe I need to move it up the list. And sometimes you're just not able to do it. But there's a dynamic process of give and take here of balancing trade-offs to figure out what you're going to do. So if you're the product owner, the question you need to answer for people, what you need to communicate is what I want and I need here. First thing. And then you, as a product team, need to be asking the questions of your product owner. How will we do this? We're asking of the questions and of each other. How will we do this? And what is the complexity here? Now, when we talk what I want, what I need here, it's broken down. It's our stories and our acceptance criteria, which we covered last week. As a, I want to do x so that I unlock this value. As a, my role, my persona, my interaction with the product, I want to, some operation you want to do, some task, so that I can unlock some value. And then for each one of those stories, there's going to be a set of acceptance criteria that talk about a feature, i.e. a story, and the scenario, and then the criteria that define it to be acceptable. And remember, we talked about that as definition by example. We talked about Gherkin as a tool for doing that, all things that you could do. Now, here's the thing. You're going to take those stories and they're not going to stay the way they were. Because along the way, you may say, we got to break this down. Now, hopefully, this has been done before. But in the process, you might go, oh, God, that's kind of big. I can't get my arms around it. Let's break it down. So break it down. Follow the process of stepwise refinement. You start with something big. Let's take the example. The story is, as a shopper, I want to go to FairPrice, what's that one called? They're FairPrice, it's a special kind of FairPrice. What? Yeah, as a shopper, I want to go to FairPrice Finest to get my groceries for the week so that I'll be able to eat. Now, that's a really big story, OK? And so we actually might refine it. As a shopper, who is a carousel employee, I want to go to the FairPrice Finest at 100 AM to do my Shiappi for the week. And you may break that down. Hey, the first story is getting this due to FairPrice Finest. And then there's a story which is you get x, you get y, you get z. You check out. As a shopper at FairPrice Finest, I want to check out so that I can purchase my goods and not be arrested as I leave the store. And then maybe there's another story which is, it's me, I live over near Amoy Food Center which is getting me home. So you might have this story that I just gave you and we broke it down into maybe that's 10 stories. Now, that's probably a process that needs to happen before sprint planning, part of an ongoing conversation. But it could be during the sprint. People could just go, remember I said, maybe this story is really big. There's no way that we can get it out in the sprint. So maybe break it into three stories. Each one of those which captures deliverable customer value and then we move forward from there. So and as you do that breakdown, you need to look at the acceptance criteria and you need to refine them. But again, hopefully, unless this is just like, oh my god, yeah, we've got to break this really big one down into a few stories, that's been done beforehand. And guess what, all of you people on the development team have, of course, done your homework before time and reviewed these stories and the acceptance criteria. Because what you're doing in the sprint planning is saying, iterating through that, let's ask some clarifying questions. If there's any clarifying questions we need to, let's then ask ourselves, how do we do this? And then what's the complexity here? Any questions at this point? So talked about how we do this, break it down, stepwise refinement. Now we're going to talk about complexity. So when we talk about complexity and estimation in the scrum world, we are not talking about time estimation. We're talking about perceived complexity. Perceived complexity. Has anybody here ever done a cardiac stress test? OK, so in a cardiac stress test following the Bruce protocol, they have you on a treadmill. When they start off, they'll treadmills level. The treadmills may be at 3 kph. They've got you wired to an EKG. So they're listening to your heart. They might even have something in your mouth, measuring your blood oxyxation level. This can be either done to see if you're going to have a heart attack and fall over dead, or it could be because you're a really elite athlete, or it could be because you're both. And what they do is along the way, they say, OK, three minutes in. How difficult does this feel? And you hold up a number. OK? Do they, do they, do they, is there like some magical scale of what is 3-Me note? It's how hard on a scale of 1 to 10 do you think it is. Have you ever been in A and E with a bad injury? Or had to go to an orthopedist, like I did with a fractured hip last year. Then they're going to ask you, they're going to say, on a scale of 1 to 10, what's your perceived level of pain? Of course, us boys start saying nine at things that women go, oh, god, you babies. You'd die if you had to have a child. So different scales. And you notice that? Different scales. Different scales for different groups. Different scales for different people. If you are an elite Olympic class athlete who's been running fire trails that you see, Santa Cruz, where I went to college for years, then you're going to probably run the Bruce protocol and break the treadmill. And you're going to say, yeah, that was about a six. Now, if you're someone who's out of weight, who hasn't been exercising, hasn't been working out and everything, you're going to probably go, oh my god, three steps in, oh my god, nine. Again, it's about perceived difficulty, perceived pain, perceived complexity, not time estimation. You are not talking about person hours. If someone says person hours, slap them. If someone says person days, slap them, OK? Because that is not going to help you. Humans cannot estimate in absolute terms. If you show two distances, two lengths, to the average person, everybody can tell you which one's bigger than the other. They can even probably tell you a relative difference in size. From three objects, they can tell you a relative difference. Oh, that's about one half of that. That's about two times that, which means that's four times that. They can do that thing. But if you ask people, is that a meter? Everybody, show me a centimeter. Hold your fingers apart, centimeter. Well, he's twice what you were. And I saw similar kind of variations around here. It's something we're not good at. We are built. We are wired for relative relationships. If you want to learn more about this, read Thinking Fast, Thinking Slow, about the work of Daniel Kineman and his partner who won the Nobel Prize for Prospect Theory in economics. Very much catches this. Read about various cognitive behavior, cognitive psychology, cognitive bias. But you'll understand, we're not wired to talk about person days or person hours. We can say things like, yeah, I think I can get this done in two days. But if you say, well, how long is it going to take? I can't tell you what it's going to be one day, half a day. But I can kind of get you. This is smaller than two days worth of work. So this is where we get to the infamous story points. Story points are about perceived complexity. Does anybody recognize what this is? No cheating if you know what it is. What is this sequence here? A number in the sequence is the sum of the last two numbers in the sequence. It's Fibonacci sequence. Turns out that it's all over nature. Fibonacci signuances are all over nature. And you will find them. For whatever reason, nature likes them. We find them beautiful, et cetera. A nautilus shell is a Fibonacci sequence. If you've ever seen a nautilus shell. Ties into fractals and things like that also. Why this? Well, the reason we want to use this for estimating, doing our estimation, is because it forces us to not go into linear sequence. And go, oh, it's twice as hard as that. No, it's like, OK, does this feel a 3? Or does this feel like a 5? Now, how would you go about this? Well, some things you want to avoid when you're doing estimation is called anchoring, which is someone put something out there and you latch on to it. Another one is called acceptance bias. Everybody else is saying this, so I guess it's right. Everybody else might just be one person. But how our brains are wired, we're wired to do that. So what you will do, one of the ways to do this, and do it effectively, we call it planning poker, is there's actually cards you can get that have Fibonacci sequence on it. You get a deck that has seven to 10 sets in there. You hand it a Fibonacci sequence to someone. And what you do is you all have the numbers and you have your cards there and then you go, OK, everybody, what do you think? Everybody pulls a card out and together you put them down on the table. So you pick out one of these numbers. Now, one thing here, you notice I dropped the one out. I think that one becomes a default position. Somehow people just drop into one and they really don't think of it. But if you force them to have no one, then they start looking at the gradations between 2, 3, and 5. So I dropped the one out because I think it's a thing that people tend to anchor on. Now, of course, we could go up to 21 here. I don't think that's very helpful. A 21 is probably too big, should be broken up. 13's are probably too big and should be broken up. Now, let's talk about the planning poker process. So what happens? You have your cards out there. Each of you have five cards, maybe six. If you have a one, you put your number down. Now, if you all agree, wonderful, you're done. You know what? If you put five engineers in a room, you have seven opinions, OK? This is the reality. So you're probably not going to agree. How do you resolve this? Well, what you do is you ask the person who's the high to explain their position. Why do you think this is? You ask the person who's low, explain their position. Why do you think that is? And you re-vote. Now, what you tend to find is you'll have a high, low, and probably a cluster. It's not always true. If that's not the case, then you may have to ask, OK, why do you think that, Daniel? Why do you think that, Albert? Why do you think that, Robin? Why do you think another Albert? OK, second Albert. A1, A2. Why do you think that, Janhau? Why do you think that, Diana? Why do you guys think that, OK? So you do that. You run through that. And then you re-vote. What will happen is there will be a process of convergence. And you'll get it out. My advice to you is go high, OK? Bias high, OK? Bias high. Now, I don't mean that if someone has 13 and everybody has three. But maybe people should move. You should consider, OK, there's a signal there from that 13. He didn't convince me, but there's a signal there. So I'm going to go from 3 to 5, OK? You iterate through this process. And then whatever you settle on, that is the story points for that story, OK? Now we'll talk about story points. Story points are useful for a couple of things. One is they help you to find a velocity, a consumption pattern for your team. And what that becomes is it starts becoming something that you can kind of say, OK, last time we estimated these stories were 70 points. We committed to 70 points, and we didn't have anything to do for the last two days. Then you should probably up your estimate. The other thing is, oh, God, we estimated 70. We delivered 30. Maybe we should drop our commitment going forward, OK? Because remember we're talking about an empirical process? What do we do? We have an ability, transparency, ability to observe. We inspect, then we adapt based on that. This is what's going on here with your velocity. Over time also, here's the reality. Over time is a team gels. Have you ever noticed towards the end of a project, it's like you're getting a heck of a lot more done than you did at the beginning? You understand the code base. You've made a lot of decisions. The team is gelled. You know how to work. I know how to go and talk to Daniel and not set him off. Albert has learned how not to set me off. 8-2 is just rocking because he understands the code base. We're all moving through, OK? And this is all good. This is all to the good. So you should expect a velocity to increase over time. Now, of course, when you get to the end and you start something new, you're probably going to collapse back down to a new velocity. If you've been working as a team, and you've done an epic, a set of features that are related, and then you move on to a new epic, don't expect that your velocity is going to be what you exited at, OK? Now, that doesn't mean that you can't say, oh, we were doing 70 points. Let's commit to 70 points. And you know, oh, gosh, we hit 40. So let's adjust down, OK? So that's the thing. As you pull stories in, you'll do that. So remember I said, you shouldn't be trying to figure out what these things are. It should be more about clarifying questions and everything. Why? Because this is going to take a lot of time. But how do we do this? How do we do this? How complex is it going to be a discussion that is going to involve some time, some conversation, some capacity, OK? Any questions about perceived complexity? And why? Not hours, not days. Now, again, it's about perceived complexity. So something that's very complex may need your best engineer on the team to tackle it. It might require multiple engineers because of the skills involved. That's fine. That's captured in the points. But the thing is, if you start saying, oh, this is going to take person days, it might take, because Daniel's fantastic as a rock star, that he's going to get it done. His perceived complexity is about five. Now, Albert here is an intern. Please, I'm not trying to slime you. And he's going, god, I don't even know where to start. 21. OK? It's a different perceived complexity for them. And so that's also kind of you're thinking about who's going to take the lead on it. Who's going to tackle this? What is the perceived complexity? Who is going to have to be engaged in it? That's all caught up. If you just do a simple person hours, person days kind of thing, that doesn't capture it. Because Daniel is a different person from Albert. Oh, this involves concurrent programming. Oh, well, Albert's got that nailed. Daniel, on the other hand, not so good in concurrent program. But if we're talking about a large data set and reducing that down, Daniel's got it nailed. Different people, different skills. So inspect, adapt, inspect, adapt. See, it comes even here. Now, in terms of perceived complexity, I always put this in, but can you do it in two days? Do you think you can get that done in two days? Don't make that two points. But do you think you can get it done in two days? If you can't, break it down. It still might be a 13, but break it down. OK? Questions? Now, I'm going to talk about something that's non-standard. It's not an accepted part of scrum. But I think it's a really, really powerful tool. People talk about backlog grooming. Backlog grooming means kind of going through, looking at the priority of the backlog, filling in details. And that's fine, but it never really happens. So what I recommend is that you actually have this thing outside of the cycle, called story time. And you do this as needed to kind of keep a reasonably full tip, because you're doing that tip of the product backlog is what you want to work with. So you want to be iterating over that tip. And getting the questions, because some of these questions that might come up, engineers, real pain in the ass, we're going to ask questions like, I don't know that. Oh, I got to do some research. Let me pull that data up. You don't want to do that in the middle of a meeting. What do you mean in this acceptance criteria? That kind of thing. And also some of the breaking down. God, this seems like really big. You're in dreamland if you think we're going to get this done in the sprint. This is like two sprints worth of work. So tell me, what would be the shippable subsets of value in this thing? How do we break it down? So story time is something that you do on as needed basis. Now, here's the thing. You do not want a well-defined product backlog of 100 items, with 100 well-defined items. Maybe two sprints. Because what might happen? Things change. What the customer wants may change. It may be a different piece of the work we're going to do. It's like, we define out this nice, really beautiful backlog that's for, gosh, we've got a product backlog that will cover two quarters. Let's go at it. We've got everything to find. It's ready to go. Things change. Our understanding changes. So what you want to do is you want to minimize the amount that you do, that you've invested, because you might throw it away. And what you throw away is waste. In addition, the reality is your understanding will evolve. But the thing is, if you went in with an understanding that's fixed, you're going to have preconceptions when you come back to the issue. You're going to say, oh yeah, we understand this. Actually, you don't. But you're not going to take the time to access the evidence because you're anchored on an understanding of the issue. You already know this. Come on, we worked it. So I was like, yeah, yeah, that's, you know, and you might be off in left field. If you haven't spent time to learn about common cognitive biases and how they affect us, take that time. I'll try to next week have a reading list, and I'll try to throw some books on cognitive bias on it so that you guys can look at it, but along with some other books. Any questions here? Yes? So we're having this story that do we expect the whole team to be involved in that? No, it doesn't have to be the whole team. But it has to be a subset of the team that can represent. So the PO has got to be there. If you've got a product designer, you probably want them in there. And then you probably want somebody who can cover the waterfront, who kind of understands the reach of the product. Could be a technical lead. You might have a couple of technical leads on the team in different areas. Whoever is going to be the best person to speak about it. And you should think about what it is you're going to talk about, and who should be in that meeting. Now, when you get into sprint planning, you want everybody there. Do you cover design during that grooming phase? You just cover some level of design during that grooming phase. Both product design from the point of view of what's the user interaction at a very high level going to look like? What's this flow? Person opens the app. They go to this tab. They select this item. That's going to get refined, but at least have a basic idea of it. Because it's going to, in fact, oh, well, we've got to maintain states between sessions. Yeah, yeah, it's like, oh, well, this human interaction that we have, this user interaction we want, requires that we maintain states between sessions. Well, that's, you know, can't do that in the app. We're going to have to write that out to somewhere, and it's going to have to be quickly accessible. Boom, that just changed your understanding of things. And then also start thinking about the architecture. At a very high level. I talk about when I talk about, you know, there's this common thing in kind of lean startup, lean development, the simplest thing that works. And I say no. The simplest thing that works that you can evolve. There are a lot of simple things that work that you can't evolve, OK? And so this is things like, OK, think about an abstract contract, OK? Or a contract that very clearly hides the implementation, OK? It might be a little bit more work to think about it and think about the things you need to pass in and such. But, you know, hey, global variables are very easy. There are. Just grab that value, grab that value. Fantastic. You know, you don't have to go learn some function to find it and, you know, and everything. It's like, just grab it. You know, interpret it in the code. Great. But it's not very evolvable. You change the underlying implications, it's broken, OK? So, yeah, you want to be thinking about that. So you want to be asking yourself that question. The simplest thing that works, that can be evolved. Always be asking yourself that question. You know, don't over engineer. Don't, you know, get down. Don't start talking about, well, we're going to use Cassandra here. You know, you know, that may or may not be true. But, you know, oh, we need a key value store, OK? Yeah, we need a key value store. This is key value pairs. We need to have a way that we can add things to the list of sources dynamically and have those be worked, you know, to have those be accessible. You know, those are kind of things, questions you can be asking yourself. Did that answer Robin? Great question. Thank you, by the way. So, hey, it's questions time. So Robin is safe, but if nobody asks something in 60 seconds, I'm going to pick one of you at random. You better have a good question. But Robin's safe. He got immunity. Yes? I'm still not ready to hear about how the complexity of the I guess the whole thing. So again, how it's asking. Not clear on the complexity of how that works. Do you run? Are you a runner? Yeah. Sometimes. OK, you run sometimes. I have a t-shirt about that. It's a fun t-shirt. So you run sometimes. I run half marathons and marathons. If you and I went down and I said we're going to make three laps around guarding by the bay, and then Daniel here asks us, so how difficult was that at the end? On a scale of 1 to 10, are you going to give a different number than me? Definitely, you are. It's perceived difficulty. It's perceived how tired I am. There isn't an objective measure. Yes, we could talk about our blood oxygenation levels. We could talk about our heart rates, all of those. Yes, those are objective data. But the reality is, at the end of the day, it's how hard did you think it is? I bet most of the people in this room have I said, hey, Saturday, we're going to do around the island bike ride. Most of the people in this room are going to go, oh my god, no way. I know that there are some people in this room who go, yeah, I'm there. It'll be fun. Different perceptions of complexity, of difficulty. So what we're doing there is we're applying the same principle to difficulty. You, with all your experience, with all your expertise in this area, using this Fibonacci sequence, how difficult do you think it is? Why do we use the Fibonacci sequence? Because it keeps you from going, oh, up one, up one. It forces you to think of things in steps. Because that step, well, it might be 10% or might be 20% above or 10% below. But those steps force you to think about what is the relative perceived complexity of this thing that we're going to do. Different teams looking at the same set of work are going to have different point scores. Point scores are not comparable among teams. A point score, a point and a velocity measure, is only applicable to a team working on the same code base, the same area. If we take a team up, if you're the team that is doing dynamic bidding, and we drop you into do payments, point scores are all, your points are going to be different than the team that was sitting there doing payments before. But what you're saying is, OK, when I think about how difficult this is, what is my perception? I mean, one way of thinking about it is, oh my god, I'll never get that done. That's probably a 21. I can knock that out without breaking a sweat. That's a two. I'm going to make some challenges here, but I think I can do it. Five, maybe an eight. You know, in terms of how you think about it, it's perceived difficulty. Over time, as a team, you are going to develop an understanding of complexity, a shared understanding of complexity, and you're over time that you're going to converge. When you first start out as a team and you do the planning poker, there's going to be people that are way off. Over time, your understanding will converge. There's some strengths. There's some goodness to this. There's some downside. You can be blindsided. You'll have blind spots. That's why you need to understand cognitive bias and be thinking about that and creating tools and processes that undercut or protect you from cognitive bias. Does that answer your question? So the other question you have to be asking yourself is, looking at all the other work that we've signed up to do, do we think we can complete this in the sprint? And another question you ask yourself is, do we think we can get this done in two days? Now it might be the whole team working together for two days because it's a 13. But can we get it done in two days? It might be that you have a resource that you're bottlenecked on. Maybe Albert here is the only person who can do certain things. Bad idea, single point of failure, best number of one, bad idea. But it happens. It's reality. So Albert goes, OK, yeah. Yeah, I think I can get that done in two days. Now that's the other thing, is the person who's going to do the work, the people who are, which you may not have decided at that time. But if it's like you've got a bottleneck, then I shouldn't be telling Albert, oh, come on Albert, it's only a two. No, I kind of think this is a 13, Jordan. No, no, trust me, it's a two. He's the expert. We're going to let him make the call. Now the thing is, again, this is remember, we're talking about an empirical process. We want to have a transparency. We want to have visibility. We want to have measures. And we want to inspect those frequently and adapt based on those. Inspect, adapt, inspect, adapt. Each sprint, you're basically going to inspect. You know what? We said that this was 40 points. We thought we could do 40 points. And in fact, we pulled in three stories along the way. There were an extra 10 points, 50 points. Yeah, well, now we can probably capture 50 points. We thought we could only do 40, but now we know we can do 50. And with that sharpened understanding, you go and look at the next sprint. And it's like, oh. And the thing is, is because as you learn a code base, as you learn a problem domain, as you understand what the acceptance criteria are in kind of a global contextual sense, what happens to complexity? It drops. It drops. So the thing that was 13 points at the beginning of two quarters ago, as you started working on this, that you're like, oh my god, there's no way I can. This is really difficult. We had to work weekends to get this done. You're like, ah, I can do that. No problem. No, we understand that because we built that. Oh, by the way, we refactored that code to make it easier. So as your understanding developed, again, back at the bottom of the empirical process, your understanding will grow over time. Through inspection, you will learn more. You will adapt based on that. You'll continue that cycle. Things will unfold. OK? Yes? So give me the first one and I'll answer that and then go to the second. So the question is, you're going along and you're understanding the scales fall from your eyes, and you realize there's no way on God's green earth that we're ever going to get this done. This is Stephanie's question. So what do you do? There's a couple of things. One, you can just take the hit, and that's fine. It's fine. You might say, oh my gosh, you know what? We thought this was, we thought that the rest of this work was 20 points, and it's really 60 points. That's fine. You're just going to know that you can't, that you're going to do a smaller chunk. And then when you, and we're not going to get some of it done, we'll take that understanding to the next sprint. We'll use that to expand our understanding, because you can re-score at the start of the next sprint. These are going to go, you know what? Remember when we thought that was three? It's more like 13. In fact, it needs to be broken down and all of that. Fine to do. The other thing is to basically say, God, we did not, we don't even know how to move forward. We're stuck. And that's where you pull out something we'll talk about in advanced topics, a spike, a process of investigation. Okay? And so what you might say is, let's terminate the sprint. There's, here's some unanswered, so here's a set of unanswered questions we don't know. We picked this up in story time. In the process of grooming we didn't get the answers here. There's research that needs to be done and everything. So let's, let's terminate the sprint. Let's print on the new sprint with several spikes to explore these things out. Daniel and Stephanie, you go look at this. Albert and Albert, you go look at this. Okay? You know, tackle that, figure it out. Let's come back at the end of the sprint and figure out where we go from here. There is, there is a need for courage in scrum and that courage is to say, I don't know. Socrates said the beginning of wisdom is knowing what you don't know or as we like to talk about the known unknowns and the unknown unknowns. But the reality is you need to step back sometimes and to say, you know I got it wrong. That's hard. We want to be the experts. We want to be the people that people come to and ask. You know, it's great when people come and say, hey Jordan, how would you tackle this problem? Sometimes I just look at them and go, I don't have an idea. I got some ideas where we can start. Okay? Here's like four areas that I'd look at but I can't tell you the answer to this problem. We have to be willing to do that. We also have to be willing, and this is a very hard one in any culture but in particular in our culture in Singapore, to fail. We didn't deliver. Okay? Well, let's ask ourselves what are we supposed to deliver? It's supposed to deliver customer value. Okay? Understanding enhances our ability to deliver customer value. So if we fail but we get understanding from it, then we're ahead of the game. And this is probably, that there is probably one of the key differences between Silicon Valley and Singapore. If you started a company and it would bankrupt, how long would it take you to get funded to do something else here in Singapore? The response is probably never. I on the other hand have observed situations where a company basically called it, quit, bust on a Friday, and all of the people at that company were working at new companies on Monday. Okay? I saw our case once, company went bust on Friday, but because the founders were willing to admit it, they sat down with a new idea with VCs over the weekend and they had a check for seed funding on Monday. And the only thing that kept them from starting on Monday is it takes a lot longer to start a company in the U.S. in California than it does in Singapore. You go online, you file your papers, boom, you're formed. There, it's like you got to send it to the Secretary of State in California or to the register of corporations in Delaware. And then, you know, 48, 72, some number of hours later, it comes back and you're set up and you can do business. So we need to be willing to admit that we don't know, which at one level goes back to failure. And the second is willing to admit that we failed. Guess what? The sooner you admit you fail, the faster you can correct. Let's take this to kind of a situation. Let's say that we're talking about an engine, some kind of motor, a jet turbine, okay? A gas turbine in the power plant. If we look at the data and we say, and the data indicates that it's about to fail, and we're unwilling to admit that it's going to fail, what happens to the turbine? Blows up. If we're willing to say, oh, we're redlining it right now, we need to cut back, cut back how much power we're demanding out of it, we need to adjust if we save a turbine. But you understand, you admit it failure. You were unable to operate that turbine as specified. And there might be consequences. That might mean a brownout for your power customers. Okay? But is it better than a multimillion-dollar turbine blowing up? Yes. So ask yourself, when you admit that you failed, what are you learning from it, and how does that learning change how you approach the problem? Stephanie, you had a second question? What? Yeah, I think the bugs... Now, the thing about bugs is that bugs really do have an exploratory or a date problem. But most engineers, you show them a bug and they go, oh, that's when I... Yeah, I already know what that is. God, yeah, I know what that one is. Yeah, in fact, they're written around that case and dealt with that. That's a two. Okay? The other one is, oh my God, race condition. This is only appearing in production. We don't have a reproducible case. This involves multiple processes running concurrently. Probably a blocking problem. Maybe some part of the banker's algorithm at play here. 21. Yes, I think that, you know, we talked, we'd go back, going back to the picture. I did you a disservice here, because there should have been bugs in here too. Okay? Is a fix to a bug customer value? Then it should be in the periodic backlog. Then it should be in the sprint backlog. Now, one of the things you run into, and this is where we talk about combat and such, is sometimes those bugs can't wait until a sprint. It's like, we need it now. Well, how do you deal with that? There's a couple of ways, and we can talk about both, two of those real quickly. One is that you are not using Scrum, but you're using Kanban, which we'll talk about as in a process, and you basically shift a whole bunch of stuff out of work in progress and pull this in as work in progress. You maintain what's called a whip or work in progress limit, which is how many items that you're working on in parallel. Usually, if you're a team that's doing pairing, then it is team divided by two. If each person is working independently in parallel, then it's no more than the team size. Okay? And the other way is to actually have a team that that's their whole job. Their job is to troubleshoot and fix issues. Now, it turns out that there are, when you've been working on a project for a long time, there are people really senior who just hate those problems in the product. And they'd actually just like to go fix them. So you're going to build this team and rotate some of your most senior people into it. And then what you do is you have these senior people here. And then what you do is then you bring in some junior people, and they work with the senior people, and they quickly come up. You know, you've got these guys who are fresh out of college, and in six months, they know the code base backwards and forward. They know it better than people have been there for two years. One, because they just had to jump around it. And second, because they were working with these real senior people. Sometimes it's called a support engineering, customer response engineering, customer issue engineering. You can come up with the idea that they're the firefighters. They deal with the car wrecks. Other people deal with driving the buses back and forth. But it works. Ways to approach it. There's other variants and everything, but yeah, it's work you're going to do, included in your backlog, sprint, and product backlog. Force the product manager, the product owner to say, how important is that? Because the reality is they come to you and say, these are all important. These are all priority. Well, actually we go to the Latin roots of priority. It refers to the one. You can't have multiple priorities. Misuse of the word. Priority, singular form. So force them to do that. There is always a stack, right? There is always, I want this before I want this. Now that might be a decision tree. If you can't give me this within two weeks, then I want this over here, in two weeks. But if you can deliver it in two weeks, I want this, and this can wait. So again, it's laying out that decision tree, that hierarchy, and how it works. Other questions? You look like you were about to ask one. And your name is? Hi, my name is Cok Chow. John? Cok Chow. Cok John. My question is that in a spin cycle, what do we do on a retrospective step? Next week. A retrospective at the very high level is you're asking three questions. There's different forms they can take. I'll do a couple of forms. The first is what went well? What didn't go well? What can we improve? Or another way is what made me sad? What made me happy? What will make me happier in the future? Different ways of asking the same questions. The retrospective is, at its end, it's actually all about, though, that list of improvements. Because we want to do more of those things that made us happy, fewer of those things that made us sad, and we believe that this is a way that this will happen in the future. But we'll go into a retrospective, how to conduct a retrospective, how to avoid your cognitive biases next week. So next week will be sprint review, retrospective, and advanced topics. I'm not sure if you've covered this question in previous sessions because it's my first session here, but what are the tools you use in Sprint? So I talked about the artifacts. There's lots of tooling that support that. And you can use those. The artifacts. I mean, you can do Scrum with a wall, some tape on the wall to create lanes, Post-it notes with tape across the top, or index card with tape across the top. You can get fancy and use Post-it notes if you need to. You can do all that. You can do this with index cards, sharpies, some tape. That's all you need. And a piece of paper and a ruler. And from that, you can build a board with swim lanes. You can, you know, so kind of attach storyboard, storyboard that tracks what you're working on. You can also then, you know, you have that. And then with a piece of paper, okay, really easy. Now, you also can then. I don't think that that, I think that there is something very inherently satisfying about moving a Post-it or a card from one place from work in progress, in progress. Done. There is something very, very physical artifacts. But, you know, not always the easiest to share it. You have to go out and look at it. Generating burn down charts. Somebody has to sit there and calculate the curve, the burn up or the burn down. You know, looking at the data in, you know, what was the average lot? There's a lot of bookkeeping you have to do. So you can use a tool like JIRA. It's a great tool. It lets you maintain this. They put a lot of work into their agile tool sets. They support both Scrum and Kanban. They have a thing called portfolio that lets you kind of do a Scrum of Scrums kind of thing we need. Great tooling. But, at the end of the day, index cards, sharpies, tape to make lanes on a wall, permission to put stuff up on the wall. Sorry. Piece of paper and a ruler. That's all you need. Now, of course, do not let me write the cards. When I was at Yahoo, I was forbidden, even though I was a product owner, from writing story cards because my handwriting is so crappy. Someone made the comment, so how did you end up in engineering management and not in medicine, Jordan? But you can do it. You don't need... Just like when you start talking to people about curly brace languages other than Go, you will get into religious wars about where does the opening curly brace go. You will get into religious wars about what's the best tool. My opinion in this area is drawn from Winston Churchill and his wisdom about democracy, which is pretty much, JIRA is the worst possible tool out there except for all the others. Okay? And so it's like, yeah, you know, Devil I Know, it works. I think things like Trello were actually too lightweight. Okay? You know, and in terms of gathering statistics and such, just aren't a real powerful tool. You know, I think people can go in saying with JIRA and how they set it up and how they use it and, you know, and you should avoid that. Kind of go as lightweight, as shallow as you can. You know, when somebody is at it, 15 custom fields, you're probably heading for a lot of pain. Others? So, who's here has been here for more than one? I think I've gotten a good view. For those, first, starting with those who have been here for more than one, have you found it valuable? Well, obviously you came back, okay. For those of you who weren't, those of you who've been here before, did you find this useful tonight? Just raise your hand. Oh, you're all going to make me feel bad. Okay. Yeah, go ahead. We have a big team that's formed and the perceived perception of this actor's story is all very diverse. How do you actually get us to get a centralized actor? How do you get that? So, goes back to the process I was talking about earlier, Jero, which is what you do is everybody goes and then basically you cluster those, first off, and ask the person who's high to say, why are you high? Ask the person who's low, why are you low? Flip the cards back over, re-vote. Okay. You might have to iterate through that a couple of times. As I said, bias high. Listen to the person who, if there's someone who's going to do the work, listen to that person, if you're finding it really difficult to come to a consensus, it might be because you need to break it down, because people can't get their hands around it. So ask yourself, okay, what is a piece of this that we can understand? And when you're thinking about, you know, you're creating, you know, a class and you're defining methods, you think about these bite-sized chunks of work that you're going to do, you know? And, you know, if you're like, you know, Ruby, you know, you might end up with one-line methods. Okay? Or a couple of lines methods. Maybe it's an iterator running across something. But it's, you know, I understand how to write that. You know, break it down to the thing you understand. If you can't agree, it's probably because you don't have a shared understanding. Now, you also might have a diversity of skill levels on the team. You know, you've got, you know, Daniel here who's, you know, been working in this code base for 12 years and, you know, you're the, you know, the fresh hire. And you guys, you know, bringing, you know, different perspective and everything out of it, that's okay. But that might be part of it too. It's an iterator part. Inspect, adapt, inspect, adapt. Just, just, just make that your mantra. Inspect, adapt, expect, adapt, inspect, adapt. Everything, you see, if you look through the lens of that, then all this stuff starts making sense and you know what to do. So, to inspect it must be transparent. If it's too big, it's not transparent. Break it down until it's transparent. Then you can inspect it and then you can adapt based on that. Other questions? First of all, I think it's great that you've touched on the topic about complexity and its relative, it's a very important one. The other one, and I like to ask, is this on prioritization? Right, it's been prioritization. So, maybe this is a bit of a cheeky question, but would you go for the low-hanging fruits? Or would you go for, would you try to take the more complex project? And I'm throwing this in, given that they have very different payoffs, let's say benefits, right? So, let's say the big project is a lot more complex, but it's going to bring you a lot more benefit. That's a small project that when you accumulate, might not bring that much benefit, but it's still a significant one. So, first thing is, how this was stack-ranked going in, that should be a reflection of the perception that the product owner has of the customer value, which might be the value to them or it might be them as a proxy for people. So, yes, you should inform yourself by that. But the goal is to complete as much customer value as possible. An incomplete story is of no value. So, one of the things is, again, do you think you can get it done? So, one is, yeah, let's just take these, and if you can parallelize the work, have everybody jump on one story at once and knock it out really quickly. And then move on to the other, move on to the other, move it on to the other. Which one you tackle? That is actually up to the development team. That is the engineering team. They're the ones who decide how the work gets done. The PO, the product manager, decides what work gets done. The development team gets to decide how it gets done and how much they commit to in a given sprint, in a given quanta of time. So, I mean, both, depending on situation, both can be the right answer. If that big story is the centerpiece of your sprint goal, then God just, you better get it done. Maybe knock it out first. Eat that frog kind of approach. But maybe it's like, nothing is really the centerpiece and that thing's more complex and has more uncertainty. It doesn't have more uncertainty. I mean, here's some things to ask yourself. Is there more uncertainty? Is there external dependencies? So we better dive into this. But also remember that something can be worked on and then move back out of work. In, out. That's an acceptable cycle. You move it in, you do some inspection, and you're like, oh, we've got to split this up into a couple of stories. And that's fine. Okay? It's fine. So kind of, you know, there isn't one-size-fits-all answer. You know, but first off, how it came in, how that was organized, that is the perception of value. Now, sometimes people will, you know, put a story value, especially if you move into an agile, into a lean methodology. There'll be kind of a value attached to it. Sometimes that's dollars, you know? I've asked, I've, I've, I have asked as a product owner, I've asked, you know, I've gone to salespeople and said, here's five things we're looking at. Tell me how many deals you can close with this. Tell me each deal and how much, you know, like, you know, we have four packages. Tell me how many of each package you could close if I deliver this. Great way to figure it out. Great way to figure it out, you know? And I've made this quit working. Oh, well. I did something that killed it. Oh, well. Ah! So, yeah. Other questions? Yes? You mentioned about spike, right? Right. So do you plan a spike during the sprint planning in parallel with your stories? A spike is a former story. We'll go into that in more depth next week, but it's just something where the deliverable there is a decision. Okay? It's, we're going to use MySQL or we're going to use Postgres. It's, we're going to deploy on Ubuntu versus Genuto, you know, you know, Red Hat, you know, Fedora, pick your, you know, your poison. It's, it's, it is, it is a, and the acceptance criteria there is, you know, you define up front, we're going to measure these criteria, you know, this is how we're going to do it, and then it's how you do that work, you know. They, spikes can be, go from kind of fuzzy to extremely fuzzy in terms of what you know going in. So if you have a case where maybe you're started with the sprint, and then really, maybe you have a couple of days and you will let it go, you don't know how to do this. So that's where, yeah. So we actually had that case recently here. What the team did, and I applaud them. This was great. They were about four days in. They realized that they, what they thought they knew was completely wrong. They abnormally terminated the sprint. They planned a one-week sprint with three spikes in it, and that was all they delivered. And I was very proud of that team because they admitted what they didn't know and they, they, they failed. But in failing, they paved the way for greater success. I couldn't have been prouder of the team, okay? But if you know that there's things you need to know, the other thing is, there's also a process, as if you're doing this, where you need to think about long pull, long pulls. Like, for example, one of the long pulls I had when I was at Yahoo when we were deploying Chef was we needed to have ACLs defined for us. And that is actually a fairly involved, lengthy process. It's not self-serve. It's not like working with, you know, VPCs in AWS. And so we had to figure out what we wanted up ahead and we had to request those. And so we had to be, as I like to call it, driving ahead. So when I, when I learned to drive, one of the things that they taught us was, you know, you should be driving, you know, 50 feet ahead 250 feet ahead, 1,000 feet ahead. So you're constantly cycling through that, you know? And obviously more time here, but it should always be every once in a while looking out at that, you know, when you're driving at night and the road is, you know, there's nobody coming towards you, flip your high beams on every once in a while, flip them off, you know, just kind of cycle through that so that you're doing that. And so that, that's what you need to do, you know, is going in parallel is, what are the things we need to have ready for us? You know, because you, you really don't want to have intrasprint dependencies. When you have an external dependency, you want it to be on a sprint boundary. Okay? You know, it's like, you know, I'll start working on that thing, I need two sprints from now. You know? And you should be constantly identifying those. That's part of what Storytime does, it's like, oh, this thing you want, well that requires that we're going to need to get a Cassandra cluster built. You know? So is that something we're going to do ourselves? Well no, we actually have a team that does that, it helps, so we'll go to that team to get our Cassandra cluster built. But they've got a backlog, you know, their pipeline, delivery pipeline is four weeks. Well we should be asking for that now then. It's an iterative process of unrevealing of things. Do you remember those Choose Your Own Adventure books? Kids? So that's software development to choose your own adventure book. If you do this, go to page 37. If you do this, go to page 95. You know, go to page 104. You know, you've got different options. And one of the things that you need to be asking is, if I go down page 37, how is that going to unfold? Or, you know, it's similar to chess. You know, if I make this move, then what is the decision tree out from there? And we don't, we have to admit right up front, we don't know. And that we're dealing with imperfect information. It's like telling poker. Poker, it's imperfect information. You know, especially if you're playing the most, you know, popular form out there, Texas Holdem, which is, each person gets two tick, two cards, and then there are five cards that are dealt across the top. Three, you know, the flop, free flop, you know. So you have the, you know, the first ones, then you cross the river, you get the other ones, you get the, you know, you get three. So it's okay. Those three cards are out there. I see how you're betting. I know what I have. Imperfect information. But I've got to make a decision. So I fold, check, so I raise, you know. What does it mean that he raised, you know. And I'll, and then, oh, fourth card's there. Do I stay in? Do I get out? You know, you know, you're, you're, it's the same kind of thing. You know, what, given the information I now have, what is the decision I make? Okay. Anything else? Well, then let's call it a night for tonight. Next week, again, we will be talking about the sprint review. We'll be talking about the retrospective. We will be talking about some advanced topics like Kanban and spikes and touching on those. You know, Carousel, we're trying to build world-class software engineering organization here and helping to contribute to that here in Singapore. That's something that sounds interesting to you or might be interesting to one of your friends. Contact us. We're hiring. Building our engineering organization. Thank you and have a good evening. Thank you, Michael.