Woohoo: chunks in real life!

Yes, we've had our third refinement in which we tried to create chunks of our user stories. What I expected to happen is becoming true. It's very simple. When we create chunks we do it by three different ways.

1. Just talking,
2. Think of scenarios, we can group them later,
3. Using functional diagrams.

By talking (and writing down), you distinguish patterns which can lead to chunks. If you create scenarios you can see patterns as well by grouping different kind of scenarios. Each group can be a chunk. If you take the effort to draw a flow diagram with some decision paths, it becomes very easy to turn one path, or a group into one chunk.

This looks nice in theory, but it actually works! And the best part I didn't mention is the following. We did an estimation on all of the chunks one by one. I hoped it turned out that the chunks are estimated mostly the same size. And guess what? They were! Some are four and some are 2 story points, but the most chunks we estimated are 3 points. And given the fact that the average is 3 points, voilà, there is no need to estimate them ever again!
That's a relief but it also saves a lot of time! Woohoo!

Maybe the near future?

So, you’re the new trainee, Welcome I’m Vincent, I’m a developer and I’m also the Scrum Master of the team. This is Tim, he is tester. This is Eric he is developer as well. And this is Marc. He is the product owner. And if you take a look at the display then you can wave to Galyna. She is sitting right there. She is a tester as well. Oleg C is sitting there and in front of him Oleg S, and next to Oleg you see Andrii. All three are developers. Well, this is your desk, but I wonder how much time you’re gonna spend behind it while you’re here.

(The trainee is looking at his desk.) I think you’re wondering why I said that, right? Well, we do a lot of pair programming here. What we also do is think as a team. That means whatever you think of, during the sprint, you share with others, so that your ideas and your comments will be heard and trigger maybe greater ideas because you discuss them. See it like this: we all have our bandwidth of thoughts. This bandwidth evolved because we’ve had our life, our experience and our relationships with people and things. It looks like I’m going to make a fuzzy statement here, but hear me out.  Let’s say you have you’re bandwidth from 50 to 200 on the scale of thoughts. Let’s pretend that mine is a little bit smaller like 100 to 200. Eric’s bandwidth is from 120 to 280. If you have a thought about something that’s located somewhere in the 90’s, both of me and Eric didn’t think about it. The point is: we can have lots of thoughts and ideas on our own, and we can create beautiful things, but as a team we have an extended range of thoughts. As a team the bandwidth is now from 50 to 260. You can even go further than that. If you tell your thought or idea, the bandwidth of others will start to shake. The way we are used to think is now changing. We make connections to other parts in our memory than we’re used to. And all because you said something. Isn’t that weird and awesome at the same time? Whole new ideas come alive because different people are communicating and reacting on each other. So, don’t keep quit and don’t keep thoughts to yourself, even when you think they are the stupidest things you’ve ever came up with.

Tim, could you show us what you’re busy with? Yeah, I can show you. Come and sit next to me. Or do you want a cup of coffee first? I’ll show you the canteen. This morning I thought about our user story we’re working on since yesterday afternoon. I sat down with Oleg C and we came up with some good scenarios. But there was something missing. This morning I found out what that was and I will discuss it with him in a minute. It’s a counter scenario we didn’t think of. I think we can make some variations on it as well. We always sit down with two or three people together and discuss the user stories and come up with scenarios. Everybody is contributing in its own way and we get the most diverse scenarios. It’s pretty cool actually. Okay, let’s call Oleg, he is sitting at his desk right now. You can wave at him if you like. Hi Oleg, how are you doing? Right next to me is the trainee we talked about, Peter. Listen, I came up with an adding on the scenarios we created. Shall I send it to you, so we could have a look at it? Okay, here it is. It looks good right? Can you add it to the test suite so I can run it? I want to show Peter how we work here. In about five minutes he has pushed it to the server and we can run the new test I created. We can run it and see if it fails or not. Actually I know it’s going to fail, because we didn’t think about it at first. And it’s not bad that we didn’t think about it because we’re only humans, right? Maybe we should have discussed these scenarios with more members, but that’s maybe one for the retrospective. In the beginning we had trouble collaborating efficiently, but somewhere along the way, it kind of turned and we got familiar with each other more than ever. The best thing is, when we want to talk to someone, we go ahead and do so. Ah, Oleg calls. Okay, Oleg says that indeed the test fails and the push has been made to the server and it’s building right now. It takes up to 3 minutes and then we can check it ourselves. Oleg is now in a conference call with Eric. They have been working in pairs yesterday on this story so they probably continue doing that right now as well.

Let’s ask Eric.Yes, Oleg told me about the scenario and he discussed it already with Marc for validation and Marc thinks it’s a good thing to test as well. I’m now pair programming to fix the test. Do you know anything about TDD? We first create a unit test for scenarios we didn’t implemented yet in the software and run it. Most of the times it fails and then we can do some additions in the code and run it until the test passes. Since we have one new scenario, we know exactly where and what to fix. And we’ve been through the code yesterday, so we know what we can expect. Tim usually is trying to create some bugs by exploratory or some other fancy way of testing, while we’re trying to fix the new added scenario. We are so good at coding right now; he hardly finds something. And when he does, he writes a new scenario for it, so we can do this cycle again. If you want to join us in the conference call, just pick up your headset and you will find out how developers collaborate with each other in this team. It comes down to: one is coding and the other is paying attention and keeps the overview. Right now Oleg is coding and I am not paying attention, because I’m talking to you right now… He is now making an overload to implement the variation that came with the scenario. I think in five, maybe ten minutes we have what we want and we push it again to the server, so Tim or Galyna can run the test again. If you want to take control, you’re free to do so, just ask.

So, are you getting familiar with the way we develop here? Everyone is doing something here. That’s because of the small user stories. They make our job much easier. We get those stories by doing a bit of an effort. We call it breaking and molding. You know what we mean with that? We first get an idea of Marc while he is translating the wishes of the stakeholders and the customers. It’s one big chunk of everything together, because they don’t know what they want exactly. It’s up to us to split it into smaller chunks. If one chunk is too large and another too small, we try to break off a part of the big one and mold this part to the smaller one. That’s how we get all chunks the same size and know exactly what we’re supposed to do with it. At the same time we try to think of the most common scenarios and the chunks are ready to load into the sprint. In the sprint we evaluate the chunks and sit down with two or three members together, mostly with a tester and a developer, and we discuss the scenarios some more and think of variations on it. Ones we did that, the scenarios are placed in the test suite on the server and developers create adapters for it so we can run them against the code. I think the rest you’ve already heard, right?