Best practices for Agile Scrum
We know what scrum really is now. And we found out that it’s not about only stick to the rules. It’s about bending the rules to fit to the team. In the last years we learned that the scrum rules don’t work when you just apply them without considering the meaning of them. You have to get a grip on them and learn how to use them in a good way.
This document contains the procedures how the Defenders (current team I’m working on) evolved from the scrum methodology. It’s not said that this is the best approach, because teams differ from each other a lot, but the main thing is we have evolved through experimenting and you should too! It’s not only fun, but it’s leading you to your best practices and it’s making you strong!
Don’t get me wrong. You need to work strict on the rules of scrum for a while before you make any additions or changes to it. The goal is to find out what scrum means and what the rules are for.
Scrum encloses force
Let me first explain what I mean with ‘scrum encloses force’. If you are obligated to fulfill the goal of the sprint (and I’m talking about finishing what you’ve estimated), because of scrum, you are forced to cooperate in such a way that you eventually can comply to that goal. We all know that the first sprint isn’t going well and estimates are far off. In other words, you have to get used to the fact that you’re planning and estimating.
We started out with the common stand-up, but it didn’t work out for us. I’m talking about the three questions stand-up: what did I do yesterday, what am I going to do today and am I expecting impediments or difficulties? So everyone summed up there thing like: ‘I was working on MTN-345, I’m working on it again today and I’m not experiencing any problems.’ It didn’t help us to get things done the right way. Most of the time, all of the user stories were in progress, because we didn’t collaborate well enough.
What we’ve learned.
Let’s make one thing clear. The product owner did order the sprint for a reason (, hopefully together with the team). So the first item needs to be finished first. The second secondly etcetera. All looks very obvious, but how are you able to do that? That’s when a good stand-up is coming in. Therefore the questions at the stand-up should be: how are we going to finish the first user story? Who is going to collaborate with whom? And what progress can we make today? What is the best approach to finish this user story the best way?
So you go, user story by user story and find out what you have to do to finish it nice and smooth and have an estimation on the progress. It’s like a small (daily) planning.
For a long time we tried to do refinement the normal way. We were letting the product owner show what the customer needs and we were trying to comprehend what that might look like in Twinfield. There were not many questions, because it was a one way direction more or less. So the implementation led to a lot of misconceptions and bugs. The tester found things the developer didn’t think about and the developer touched code he thought wasn’t worth to mention to the tester. So bugs sprout out from production.
I think the reason was because we didn’t talk about the feature enough. Most of all, we didn’t talk about it at all, because in our own heads it seemed clear enough.
What we did is let the product owner create the user stories and the acceptance criteria. He was spending a lot of time on that and at the end, the team changed a lot about them during the sprint.
What we’ve learned
Now we are creating user stories together with the product owner and help him out on that. That’s purely because as developers we know the domain and the code best and we know more and are smarter as a team than the product owner is by himself.
To understand the user story correctly, you have to go through three phases. And if you don’t want to have the tester falling behind a lot, you need to make sure your user stories are very small. And that ladies and gentlemen, may be the best part of being part of a development team. Try to puzzle your way out to have the best minimal viable product and implement it the smartest way. That is the cherry on the cake, especially for a developer.
For this three phases we created a Trello board for the user stories which we need to refine. Every user story has a checklist for all of the three phases, like: ‘The title of the user story reflects the actual fix’, or ‘The team has figured out and talked about different scenario paths’. The full list will be at the bottom of this document.
Also, you need to have everyone to talk about the subject a lot! If you think you got a silly question, don’t hesitate to ask. Speak your mind and you will see that stupid questions can lead to different thoughts and perspectives and might even lead to better solutions. At least, the one who asked a stupid question, knows more about the user story now. Keep asking questions!
One thing worth mentioning: you don’t need to talk about the solution at this point. There is no need for that. It will come in the sprint itself. (In practice, you’ll find out that each one of you is secretly thinking about a solution, so don’t worry about that)
More to come on this subject in my next blog: The Three phases of User Stories.