How sprint planning helps Rakshasa
|
Hey! In my next post I’m going to bring up 2 topics – firstly I’ll briefly describe the Scrum framework that I’m practising together with my group, but more importantly, I’ll focus on single aspect of it – sprint planning. As I mentioned in my previous blog about working in a small team, having just a few people has its’ advantages. One of them is definitely the process of setting up the structure from an organisational perspective. Despite of the tight schedules of different minors that are not really matching together, I managed to lead my group into the weekly routine of Scrum. We start a working week on a sprint planning meeting from setting an achievable goal for the upcoming sprint. As a next step, we break it down and proceed with the standard procedure of planning – picking items from the product backlog, estimating time, etc. After that, during the week we work together as much as we can and report our progress daily on stand up meetings which I harshly pressured on my team (not everyone does them and not everyone wants them!). We close the week reviewing everything that has been done and making sure we achieved weekly goal. My team members agree that working in this manner and leaving as little remote work as possible fits us and we wouldn’t be able to be that efficient otherwise. The aim of the next section is giving a closer look at my team’s sprint planning. First of all, as mentioned above, we figure out the overall objective for the duration of the sprint. That is what we want to accomplish with our game and how we want to improve it. Important aspect here is taking any new information that may impact our further work into account. Agile methods are all about being flexible and in order for that to succeed, we need to think of everything that happened with the project recently and to adapt. Basing on our agreed objective, we discuss what exactly needs to be done to fulfil the goal and pick specified items from our backlog. Keeping in mind our own velocity helps us with not biting more than we can chew, and I in particular have to make sure my group is realistic when it comes down to assigning job. A hard part here is to estimate the time one needs for a task – no one really has enough experience to know his or her limits yet (but I think we’re getting better at it over time). Once the scope is agreed upon, we have a conversation on what we consider good enough and what are our criteria for that. When it’s needed, we also talk through how to implement certain features or make a design decisions. When all the required tasks are clear for everyone and each member has some job assigned, I want all members commit what we talked about. Usually there are no any objections and we finally go back to our game! In my opinion, developing a game and particularly planning in such a way is very convenient. Because of that we are able to stay at the same page and to have exact same idea about what we create. It is certainly a good practise!  |