“We tried scrum in our company, but it does not work for us. Our tasks are so complex and unpredictable, that a single task estimated for two hours might take even two weeks to finish.”
Do you think like this as well? Or did you hear such arguments from other people?
Recently I went for a beer with my houseboat neighbor and we ended up talking about work. He is a physicist, works in research and has his own company. Actually, he is building a simulation software to simulate the behavior of certain fluids under high magnetic fields.
We also talked about scrum and he told me, that they try to use scrum in their daily job as well, but it does not work for them.
Everything they do is completely new. It is very likely that nobody else has ever done those things before. That’s why you cannot estimate or predict how much effort such tasks will take.
He said: “It can take two hours, or it can also take two weeks!”
This triggered me to think: where can you apply scrum and for which type of work does it not make sense?
Well, this question reminded me on the Stacey complexity model, which says scrum works for all complex tasks.
So, scrum does definitely work also for those type of tasks.
In fact, the real question to this problem is: Why is estimating the effort so difficult for complex tasks?
What is a complex task?
The reason why some tasks are considered to be complex is that it includes a lot of unknowns. You have no clue on how to accomplish the desired result.
You probably have multiple options to choose on how to solve the problem. And you don’t know, which one is the best.
Or, even worse, you might not even know, which different options you have.
Refinement meetings
So what you are going to do to make the path to the solution more clear?
First of all, discuss the task with experts. Those experts you can probably find in your team. Just plainly discussing the problem helps a lot to identify what exactly needs to be done.
In scrum those discussions take place in refinement meetings. In these meetings the whole team gets together to discuss certain tasks in order to get a rough overview of the effort.
Well, actually refinement meetings are NOT part of the official five scrum events, but a lot of teams have refinements (also called grooming sessions) to estimate the size of tasks.
Still, although the refinement meeting is not an official scrum event, the scrum guide describes the refinement as an ongoing process in which the Product Owner and the Development Team collaborate on the details of Product Backlog items.
In these meetings the team sits together and discusses what needs to be done and how much effort it will take. When the scope is clear enough for the team, then the size of the tasks are estimated.
WHAT, not HOW
The point of the meeting is to get a rough overview on WHAT needs to be done for a certain task. You should not discuss all the details HOW you are implementing it, but just WHAT needs to be done at a high level.
Do not spend too much time on discussing details, a healthy amount of uncertainty is fine. Clarifying the last bits and pieces can be done in the sprint planning meeting. The goal of refinement meeting is to get a rough estimation of the task size.
Anyway, for difficult tasks the team can discuss the different options to complete the task. And then the team decides, which path is the best and will be chosen.
For difficult tasks do not leave this decision up to the person, who picks up the task in the sprint. Try to find the best path together and avoid one person struggling to find the best option by himself.
This might save you from wasting a lot of time, because multiple brains more likely pick the option, which is really going to work.
When the possible options are not clear
Sometimes though you might be in a situation, where you cannot even identify the possible options for solving the task.
For such cases I think it is a good idea to create and work on an investigation task one sprint before you actually start working on the task itself.
The scope of the investigation task is to research the different possible options for the solution.
Such an investigation task should be time-boxed. This means, you define upfront, that you will only spend for example half of a day to research possible options.
Time-boxing the investigation task helps to avoid spending too much time on the research. The aim is not to build a fully functional prototype, but just identify the options for a solution.
After you have completed the investigation task you should have an idea of the possible options. Then you can bring those options again in the next refinement meeting and the team can together discuss and decide, which is the best one.
If the team has identified the best path to go for solving the difficult task, it will be possible to come up with an estimate of the size. The estimation is done as usual with planning poker in the refinement meeting.
Let me wrap it up
Estimation of a difficult task is done during refinement meetings. There you define the scope of such tasks and you split it up in smaller, manageable parts.
This is done by the whole team together.
In some cases this is not working, because the task might be too complex. You might not know, how to solve it and which possible options you have for completing it.
In such cases, it helps to create an investigation task, where you spend a limited time to research different options for solving the problem.
After you have some more insights you share the knowledge with the team in the next refinement session. There the whole team will again discuss and estimate the task together.
Do you have refinement meetings in your team? How do they work out? Let me know in a comment if your team sometimes struggles with difficult tasks and how you handle it?
Ok, that’s it for this week. Take care and HabbediEhre!
