Estimating work to be done
I Don’t Know How Long It’s Gonna Take
In software development we usually work on things that are completely new to us. Sometimes we have a problem to fix, it’s not a bug per se but more of a user or business problem that we wanna fix but we don’t know which solution would work. Sometimes it’s a new technology, sometimes it’s just a smallt task but in an area of the code that the developers didn’t touch for long time and they don’t know how long it’s gonna take them to achieve this simple task because of the complexity under the hood.
Some years ago, I was annoyed by the answer “I don’t know how long it’s gonna take” because this is not an estimate that we can have on a ticket, and I think I was wrong. Sometimes this answer could be totally acceptable given the context in which it’s provided. Size on a ticket is not the true essence of working agile, and sometimes story points are pointless. I know that having story points on each ticket in the sprint is reassuring, it give us -product owners- a feeling that everything is under control, but sometimes this is just a misleading feeling 😉
When we face such type of tickets, instead of wasting time on sizing the non-sizable we just ask ourselves in the team “Should we size this ticket?” and as long as the answer is “No” then we skip sizing and move forward.
For this to work there are a few remarks
Maintain trust within the team
It won’t work if you think your team is just slacking off or avoiding sizing for empty reasons. Mutual trust is required in this case, you need to trust their judgement and they need to trust that you won’t push extra work on them through this door of non-sized tickets.
Make sure that the team clearly understands the scope of the ticket
It’s the task of the product owner/product manager to make sure that the problem we’re trying to solve is very well defined and that the individuals in the team don’t have conflicting understandings of what we’re trying to solve. One advantage of sizing is that it clarifies such conflicts of understanding between individuals in the team, so, when we can’t size we need to be very clear about this scope, to avoid ending up in scope creep or, even worse, fixing the wrong problem.
Have sprint goals
Having a sprint goal is one of the most important things you need to pay attention to as a team. I can’t emphasize enough how valuable sprint goals are. Goals help the team focus on what matters the most, and usually it allows flexibility on scope while delivering the desired business value by the end of the sprint. It’s very useful, especially when the going gets tough. However, sprint goals are not a list of tickets you want done by the end of the sprint 😉
