 All right, thanks for coming. Thanks, Yulin, for a very interesting session. I think I myself learned a lot. So for myself, I am Rampreet. I am actually a Java developer, but I have interest in knowing the software development lifecycle processes. So that's why I did my certification in Scrum and in PMP2, basically broaden my knowledge in these areas. So what I'm going to present today is Scrum ceremonies. All right, so before I start, I'll just explain some key terms for the benefit of those who are not involved in agile project or basically want to refresh themselves on. So first of all, sprint. So in the normal waterfall methodology, we have something called releases, which we do after three months or six months, depending upon whatever suits us. So in Scrum, we call it a sprint. The difference between the waterfall and Scrum is that we make basically smaller releases because we want to deliver the customer value often and fast. So typically, a sprint is of two to four weeks long. I have seen some sprints one week long also. That's fine, but as long as we adhere to some standard, some practices, it's OK. Next term is Scrum team. So what's there in Scrum team? As earlier, you'll ensure that everyone in the Scrum team is basically a member. There isn't any such thing like someone is architect or a manager. Basically, it's a cross-functional team. So we have dev team that actively does the development. And we have a product owner who takes the ownership of the product. So in the traditional waterfall lifecycle, it is basically a BA. And then we have Scrum master, who is not really a project manager, is a facilitator, brings a team together. And he or she is a process coach. And so Scrum master is basically a process coach, is a protector, in the sense that he or she will protect the team from external negative influences, politics, and all that stuff. And so it's a servant leader. What do we mean by servant leader? So it is a leader whose aim is not just to get the status update. The aim is to serve the team to make sure that the end goal of the sprint is achieved. And then we have user story. So user story is something very similar to our requirement. So traditionally, we used to write our use cases, and we used to write alternative flows, and the happy case scenario, all that stuff. Now the difference is that user story has a specific format. And I find it that this format is very beautiful. So why is it so? So for example, I can say as a customer, I want to cancel the ticket so that I can make alternate plans. So what's the good thing about this format is that it's forces me as a product owner to think, why am I building something? Sometimes you would notice that developers would add cool features, which basically are not even needed. So it makes the product owner to think about what we are delivering, why we are delivering, and it makes the developer to think about what needs to be tested. And the next term is Epic. Epic is a big user story. So user stories are typically like one-liners, but Epic is something that is at a very, very high level, which hasn't been thought through. It hasn't gone through refinements at a very high level. Then product owner has some main responsibilities like he has to maximize the business value of the product. So a product owner owns the goals and vision of the product, and he's the person who has to decide between schedule, cost, quality, so the trade-offs. And the next key term is done. So what do we mean by done is how do we consider that our sprint is successful? So there is a term called done. So what's the definition? The definition is given by the scrum team itself. So do you consider that when there is no bug in your product, then you are done, or probably you are OK with as long as the quality is acceptable, but you have some minor issues, is that done? It's up to the scrum team to define what is considered done. So I like this slide a lot, because if I have to explain to someone what is scrum, I think this slide saves a lot. So if you see in this circle, this is what typically happens in a sprint. So we start with planning, and produce, and then inspect and adapt. So on the far left side, what you see is a product backlog, which is a prioritized list of items or PBIs that need to be delivered. So this is usually prepared by product owner, but it's not necessary that he or she has to prepare it. Sometimes developers can help also, but it is owned by the product owner. So if product owner is not comfortable that a particular item shouldn't be there, then he or she has the authority to say, no, we can't add it. So what happens is at the beginning of the sprint, the first day of the sprint, we do sprint planning meeting, whereby we pick up the items from this backlog. We slice them to very small sizes, typically like half days work or something like that. And we put them on some kind of board, and then we decide that this is the list of items that we are going to deliver in this particular sprint. And the next thing is produced when we do the actual development. So in a sprint, 70% to 80% of the time is spent in the produce, where we are actually developing the product. And the next is, if you see after produces product backlog refinement. So this is something that regularly happens in each sprint. So we think ahead about what are we going to cover in the next sprint. And so then we have done increment, which is basically coded, tested, no defects. And then next cycle is, next step is inspect and adapt, whereby we do sprint review and retrospective. So this cycle goes on, so a typical release or a typical final delivery may have 7, 8, or whatsoever number of sprints. So this is the overall picture. We'll go through the detail of each. Starting with the product backlog refinement. So what happens is, before the first sprint, the product owner, development team, and Scrum Master, they together do product backlog refinement. As I said earlier, it is basically slicing of the bigger items into smaller items. So those bigger items sometimes can be bigger user stories, or as I mentioned earlier, Apex. So Apex could be like, I want a particular feature to be available on mobile. So it's such a, I mean, it's a big release in itself, right? But it can be stated by the BA in a single line. Then it allows the development team to get a more detailed understanding of the requirements of the product backlog item. As they slice through, they get to understand what exactly it entails. And the general recommendation is that we should split the item small enough that one to two people can make the item completely done in three to four days. This is a general guideline, but if you have some scenarios where you think, you know, this rule may not work, then it's fine, as long as you can justify to yourself, right? So after the product backlog refinement, at the beginning of the sprint, what we do is a sprint planning. So what the team does is, they will pick up the item from the top. Now, as I mentioned earlier, the product backlog is a prioritized list of items. So the product owner has already ordered the items in a way which are going to deliver maximum value. So in case we are not able to, you know, deliver the bottom items, at least we can be happy that we are delivering the items with the most value. So that's very important. So what we do is, when we prepare the sprint backlog we further divide the items into smaller chunks. For example, if I have to code a particular screen, right? Then the smaller items can be that I have to prepare a database script or I have to write my unit test or I have to, you know, do some UNIX coding for that. So basically we need to be as fine-grained as possible and the advantage of that is we'll be able to do a very proper estimation because of that. So the recommendation for this is two hours for each week of sprint. So if you have two weeks, you know, long sprint, then you typically spend four hours going through and slicing these items. Okay, so once we have decided on the items, we have broken down the items and the team has picked up as earlier, it was shared that team is self-organizing. They pick up whatever items they are comfortable with and the next thing is daily scrum. So it is something that happens every day. It is time-boxed, it's just a 15 minutes meeting where we'll have a demo of this at the end of it. We'll all will participate in it to get a feel of it. So the idea is that it gives us everyday reflection rather than doing it at the end of the sprint to see what exactly are we doing? Are we, you know, on track or there are some impediments that maybe Scrum Master has to help us resolve? So it's a daily opportunity to inspect and adapt. Everyone stands in a circle and answers three questions. So what have I done since the last Scrum meeting? What am I going to do until the next sprint daily Scrum? And what are the impediments I can see? If there are some questions that the team members might have with each other and then it is better that there's an offline meeting for that. So the purpose of this is to stick to 15 minutes because that's very important. If you, you know, go from 15 to 20 minutes, then it can go from 20 to 30 minutes also. So it's very important that we stick to the time-boxed approach. Okay, so what happens is Scrum Master writes down the impediments. It's generally avoided that outsiders don't come because we are talking about day-to-day issues but it's okay. In one of my projects when we had just started using Scrum, my manager, he brought another director because he just wanted to show that we have, you know, we are introducing Scrum. So that's fine. But in general, it's more of a development team activity. And time box 15 minutes per day. Okay, so once, you know, we are working on our sprint. We are having daily Scrum. We are resolving the issues proactively. Then when we are near the end of the sprint, we have something called a sprint review. So what happens is in the sprint review, it's an inspect and adapt of the product. So what we are delivering, that thing is going to be reviewed by the product owner, development teams, Scrum Master as well as stakeholders. It's very important to involve the stakeholders, not just the product owner because the end users are the ones who are going to use product. And if we are missing something, if there are any gaps and they are highlighted, even at this stage, it is better than being highlighted in UAT when the actual users test the product, right? So in terms of recommendation on how long it should be, for it's one hour, depending upon the number of weeks we have in sprint, a little bit of variation is fine. And the next inspect and adapt process is sprint retrospective. So the earlier one was basically to check what we have delivered in the IT projects. It's like showing the user actual demo and getting their feedback. Is this what was expecting or not? And but this one is more from a process perspective. How well we have implemented our agile process. So generally it's recommended that in the sprint retrospective, it becomes a meeting of development team and Scrum Master, but it is better to avoid the external stakeholders because we are reflecting on how we are doing this, right? So the current state of the process, what's going well for us and what are we having problems with? What do we want to try to do differently in the next sprint? Basically lessons that we can learn from the sprint. So there can be multiple formats in which we can do. One is you can have start, stop and continue kind of columns whereby you mentioned what are the activities we should start doing to improve our process or what we should stop or things that are working well. We just continue doing that, right? So we get the team's feedback on how do we improve? There are many other formats. For example, Glad, Sad, and Mad where people anonymously they give their feedback. They take the posted notes and stick it on the board and the rest of the team just put some dots on the comments which comments they agree on. So top three comments we can pick up from there and then we can see whether we can use these comments to improve ourselves further. So any kind of format can be there. The key thing is continuous improvement should be the base of it. We have to learn from what we have done whether we should continue the same way or we need to improvise. That's the main theme. Oops, I'm done. Yeah, so that's all I have. Any questions? What are some key challenges in doing this entire method for the first time? When you're introducing it to a team that has been a conventional method, what are your challenges in getting them used to the process? Sure. The main challenge I have noticed is change. It's a big change and people don't like change, right? They are set in their ways. So as Yolen earlier suggested that send them for training. Now people, sometimes companies don't have budget. So what you can do is if someone knows it, you arrange the internal trainings. Once they understand the concepts, right, that it's not something that's going to shake them out of their comfort zone, but it is going to help them. There are many good principles behind agile TDD. So initially I used to think that do we need to test every single thing? It's waste of time, but once I started doing it, I realized that as a developer, it has made my life far easier. So when you get people involved, right, initially with some encouragement, I think slowly they can get used to it. Apart from that, as someone, I think earlier asked this question, cultural change is very important. Sometimes the change is coming from the bottom, but the whole organization should be involved and even some companies, they send their managers for trainings. There is a training for the product owner itself. So once they get involved, they understand it's going to help them, then you can get buy-in from them. Any other questions? If not, then maybe we can do the daily scrum simulation. Thank you.