THE REFINEMENT IS NOT JUST AN HOUR LONG MEETING EVERY SPRINT

User Story Refinement – The activity of understanding what is asked of us, and the decision making of how to do it.

There refinement has two parts. The first part is to make sure that we understand what the stakeholders want. What are the problem we’re trying to solve? We have to understand how the story fits into the big picture, we have to understand how the thing we are going to do is going to be used by the stakeholders. Not the stakeholder (singular), because there are of course many stakeholders. Obviously, there is the client. The one we talked to when the story saw the light of day for the first time. But then there are all the others. For instance:

• Law. You can’t do anything without conforming to the law.
• Lifetime of the app. There are people that are running the servers. They have needs. There are developers that work on bugs. They too have needs. And what about all new features that will be added on top of the code in the future?
• Security. Can people trust that the application can keep secrets? Are we preventing hackers from getting in?
• And many more…

There are so many stakeholders that we usually don’t think of. And let me tell you, the person you interviewed to get the user story did not even know that they exist, or even care. So, it’s up to us to discover them. And when do we do that? You’ve guessed it, the refinement.

The second part is to decide how we are going to solve the problem. Some call it architecture. I’m talking about the high level thinking. Like, in the beginning we should establish if we should use CQRS or just a monolith web app. As we move down the backlog, we constantly run into similar design decisions, although not as big. This is the time to talk about it. Explore different ideas. Find the best solution.

And all the time, we will discover that we need to collect more information from the stakeholders. And it is not uncommon that they don’t have time to answer you right here and right now. So, we have to wait until they get back to us.

All of this takes time!

It takes time to find all the requirements from all the stakeholders. It takes time to decide on the solution. And it takes time to wait for people to get back to you.

This is why you want to have a backlog that has user stories for at least three to four sprints ahead. So you have time to do the work to make them ready for development. There shouldn’t be any major issues when you pull it into the sprint. The sprint is the time when you create the thing you are going to deliver. This is the time to get things done. To create stuff.

The refinement phase on the other hand, is the time for questions, to manage the unknown. I suggest to you that refinement is not just a meeting or two. It is actually the time from when the story is added to the backlog until you are finished with answering questions, when you put the mark on it that says, ready for development. And how you answer questions is entirely up to the team. Working solo, teamwork or a dedicated architect; your team, your way.

But know this, you need two completely different mindsets for each of them. Refinement = high level solutions and constant collaboration with others. Sprint = headphones on, and details, details, details.

So, what happens if you don’t do the refinement properly? What if your manager insists that you don’t “waste time on meetings”, that one hour per sprint is enough?

Well, obviously, you’re not finished. There are still a lot of unanswered questions.

First of all, when you are about to estimate story points, you don’t know what you are estimating, so the estimates will be incorrect. Since you don’t know what hides within the story, you can’t say how much work there is to do it. You will probably not have time to finish all the stories in the sprint.

Second, when you do the sprint planning and create the tasks, you still don’t know everything you have to do. So either the tasks will be incomplete, or you find out what is missing right now, and you sit forever in the sprint planning to catch up. Nobody likes a sprint planning session that is many hours long. And there is a risk that the manager shuts you off again, after an hours meeting.

Third, when you are in the sprint and try to finish the story, you will probably find some of the missing things. You have to juggle both architecture thinking together with developer thinking. A bit like reading the map when you are driving.

Or you are so focused on development that you don’t think about the requirements properly, so you leave a lot of things out. Which results in poor quality. Only half of the stakeholders will be satisfied. And the missing things have to be fixed later. If they ever gets fixed at all, because that costs extra money and time, and you are probably already over the estimated time budget and the release date is just around the corner.

Finally, you get a bad reputation for being a sloppy developer.

To everybody that reads this, please understand that the scrum meetings are there for a reason. They solve a problem. They are proper work. We don’t sit around drinking coffee and discussing the weekend. And if you try to micromanage it from the outside because developers shouldn’t waste too much time in meetings when they could be hacking away on their keyboards, it is you, yes YOU that are the reason for the failure of the project.

And on that bombshell, it’s time to say — Cheers!