DIFFERENT STAGES OF SCRUM

Scrum is not big bang development, you know, everything at once.
It is done in different stages. Each stage adds its part to the finished product.
And I put in some words about story points too.

Step 1
What: An idea is formed
Who: The customer

It all starts with an idea. It doesn’t say much about what we’re going to do, it’s more of a direction to run in. A starting point. Sure, you may have thought a lot about it, and have a pretty good idea in your head. But there’s still so much more information needed to actually turn the idea into code. It’s a great start.

Step 2
What: Creating stories
Who: Customer -> Product owner

Next step is quite obvious, start evolving the idea. Give it a little bit more body. Moving from a general thought to what problems we’re trying to solve and how to do it.

This is what user stories does. Oneliners that describe a problem, who has the headache and how do we solve it. Each user story reveals a little more about the final solution. Still not that much information, there’s still plenty we don’t know, but it’s way more than the idea we started with. The product owners job is to work with the customer to find out as many of the problems that hides in the idea as possible.

Here’s an example:
“As a customer (who), I want to add the item to the basket (the solution) because I want to buy it (the problem).”

Step 3
What: Refinement
Who: Product owner -> development team

The product owner explains the problem and the suggested solution to the development team. This is where the ‘what’ meets the ‘how’ for the first time. Or in other words, where we start adding technology to the problem. Still on a fairly high level. The problem is well defined, but the solution is only starting to reveal itself. The team asks questions to find out what hides behind the oneliners. We dress the story with that information.

This is also where we try to put numbers on the job, how much work (not time) it will take to complete the stories.

Enter Story Points.

So what good are story points then? I can start with telling you what they are not. They do not tell you how long time it will take to finish the story. Actually, they are not even close to anything that has to do with time at all. They don’t even measure anything absolute. They are a relative measurement. They only work if you compare things with eachother.

“I have an elefant. It is 3 big. Now, is it bigger?”

Notice that the number three doesn’t have any units. It is only 3, not 3 cm or 3 kg or 3 minutes… It is just 3. And the only place that works is if you have more of its kind. Like, 3 is between 2 and 5.

The only thing story points do is to tell you whether a story takes a lot of work to complete or if it will need just a litte, compared with all the other stories you have. It does not tell you how long it takes, that is an absolute measurement. And we really do not want absolute measurements. We’re doing everything we can to avoid it.

And to force people to not get too detailed, we use the Fibonacci sequence (1, 2, 3, 5, 8… Google it), which is fuzzy enough to make people not obsess over small steps. We do want it to be crude, to be rough. It really is far from an exact estimation. Especially when you get to the bigger sizes where the uncertainty of what’s included gets greater. The bigger a story, the more it hides.

So how do we use the story point then?

The very act of estimating the story to find out how many points of work it is, makes the team talk about it. We have to understand the story to estimat it. If we don’t know the full story, we can’t figure out the size of it. And yes, that was a pun. Talking about it will unevitably increase our knowledge about it. And that is a really important step in the process! Do not underestimate it (yup, another pun, sorry).

When we put a number to a story, we also find ones that are way to big to do in one step. We find stories that needs to be broken down into smaller ones. Yet another really important step in the process. A story that is that big often tells you that you haven’t thought enough about the problem, that the problem is more complex than you first thought.

Finally, the product owner gets a way to help prioritizing the backlog. Knowing which stories are big and which are small helps her make decisions about the order to do them in.

So refinement is really necessary. We know if a story is big or small, and that helps the product owner prioritize. We also know a lot more about the story so we actually know what to do when we start coding. And we only have stories that are realisticly sized, that probably do not hide too much unwanted complexity.

Step 4
What: Sprint planning
Who: All stakeholders:
Product owner, scrum master, developers, testers, operations…
In short, everybody that has work to do developing and delivering the story.

How many stories can we finish in one sprint? Now that is the question. And the Scrum process has thought of that too. Not surprised.

First, check how many story points you finished the last two or three sprints. That will give you a hint of how much work you can handle this one. It is an average value that assumes that you produce roughly the same ammount of work each sprint. And the assumption is that you are quite consistent in how much you produce, it usually doesn’t vary much. In Scrum, the official term of this is your Velocity.

But what if it is the first sprint? Guess. That’s the only way. You can always add or remove stoies. And that is expected in the beginning. There is a learning curve. Since every team is different, there is no way to know when you begin. Even an AI has to be trained to recognize images of cats. As a matter of fact, the velocity will change over time. The team gets more in synch, we learn the code base and do not have to look for everything, and so on. Or addnign a new member to the team. Or…

So, you fill the sprint with stories so that the sum of all story points add up to somewhere about what your velocity is. Add a story, check its story points. Add it to the total. Have you reached the velocity limit? Stop adding any more.

Did you notice how much work you had to put into estimating and getting to the point where you have things in the sprint? Not much! Not much at all… And that is the beauty with story points. Estimating how long software development takes is at its best impossible, often even worse.

Yes, go ahead and laugh. To start with, we’re not serial producing nails, we are not producing the exact same thing as yesterday. We’re more or less inventing new code all the day. Sure, there are patterns, code that look a lot like other code you wrote, but it isn’t. Why don’t you just pick the code from the shelf and paste it into the file, like brick and mortar? Or is it actually that we do write unique code all the time? And on top of that, we’re changing the stories as we go. We constantly find out things that we didn’t know when we started. And that will change the estimates. So how will you, with any amount of accuracy ever be able to predict the future when the time you spend on coding varys constantly and what you do thought you should be doing is always changing? Why then, waste time doing it, when you can use story points instead and reach the exact level of uncertainty but with way less work?

Step 5
What: Task breakdown
Who: Developers, testers, and anyone that will do work in the sprint.

Now, while just adding stories to the sprint is a good start, we still have a lot of uncertainty left. I don’t know if you thought of it, but in each step we uncovered a bit more of what we are going to do. And we will of cource do that in this step too. And it is time to get really specific.

It is time to think about things like what steps we need to do to deliver, like development, test, release activities and so on. Other things that are good to talk about is how we will implement the story, like what code architecture to use, do we need to do any major rebuilds to avoid spagetti constructs, do we have any dependencies to other teams that will block us and how do we handle that? This will add many more tasks to the sprint. Also, try to not just add a task that says “development”. That will hide so many things from estimation. You will underestimate. Actually, try to be too detailed.

Don’t be afraid to open the source code to clear out questions, to find out what you are dealing with. This is after all a step in the development cycle, it’s just that you have another mindset now than you have when you start coding. Right now, you are wearing the analytics hat. Then you will wear the constructors hat. Two different ways of thinking that usually doesn’t work well together. The brain either analyses or does things.

Then each task is estimated. In hours! Yes, you read correct. It is no longer guessing in the big. We no longer need the story points. They have served us well up till now, but it’s time to abandon them, we need another tool. At this point, we have enought information to be specific. We actually can estimate in time.

Just as we did with the velocity, we know aproximately how much time we have for work on the sprint. We may estimate that we have six hours per person for sprint work, the rest is for meetings, reading mail and all that other stuff. Just multiply the number of work days in the week with the number of team members and with the number of hours per day. This is how much work we can do in a sprint.

Compare this with the number of hours that your tasks sums up to and you will see if you have enough, or even too much work in the sprint. And adjust accordingly.

Now, all that remains is to start the sprint. Good luck!

— Cheers!