This is always up to debate in different communities: how to do estimates and if you have estimate at all.
In my organisation, there is no option, to be able to prioritize cost is a big factor. When it comes to software, cost is directly related to time… so we estimate in hours. Now, everybody knows that this is a guess but as professionals we take this seriously.
In my view when it comes to estimates, hours or story points, we have two parts of the estimate,
- What we know
- What we don’t know
You should try to start with what you know, e.g. boilerplates, required documentation, writing acceptans tests, and such. This you can do together with the rest of the team, make a list. Then take this list into consideration when doing the rest of the estimate.
The things we don’t know with be a little tricky. In large systems, or parts of the system that rarely changes, there is a high risk that none in the team have ever had the chance to touch that part of the system. You can’t guess your way out of this. Maybe, just maybe, if you are using Story points you can say that this is relatively complex and impose a lot of uncertainty. You might argue that the risk of the estimate being way off is low.
I would suggest that you in this situation try to gain more knowledge. This can be done during any planning or refinement meeting by just opening a computer, open you IDE and together with team discuss the issue and where the change or new functionality would fit. This is a way to quickly get more knowledge of the architecture and design principles used.
Maybe this knowledge have given you a better view of the issue and how it could fit in the design, then you are ready to do your estimate.
However, if this isn’t enough then you will to dig deeper into the code, this can be done in either way,
- Code review
- POC/Spike
- Timebox
Code review should be about 1 day of work. This is when you read code, draw some sketches, and try to find documentation. Just to paint yourself a picture of the different pieces of this part of the system. Try to understand the architecture and designs used, and figure out the use cases. Do it in pairs, and communicate your findings with the rest of the team.
POC/Spike – What is the difference between a POC and a Spike? In my opinion the difference is subtle. The POC is used when you want to test the usability of something, e.g. a new component, a new way of communicating, a new GUI, and such. The purpose of the Spike however is to gain knowledge about something, for example, What will I have to change to fit this piece into here? You implement just a small part but make sure to cut through all layers in your code. There may be other differences, but this is my view of it. If there are any other definitions of this, please let me know.
Timebox – Gain knowledge by just do what you think is necessary for 1 to 2 days, and then let the team know about how far you got. It is better than nothing, right. And you just wasted 1 or 2 days, forcefully hacking like hell. But at least you know more. Just don’t fall into the trap of letting your hack become the production ready feature. You might of course reuse parts of it, but make sure it is tested properly.
Be careful when you communicate this option to the stakeholders and PO, make sure they understand the outcome is knowledge… not working software.
And don’t just share your estimates loudly, write them on post-it, use your fingers, or use planning poker. Make sure that your estimate doesn’t affect your team mates estimates, and talk about the estimates. Make sure that you communicate. This is something that some teams are bad at, if I say 4 hours and you say 16 hours, then we can’t just calculate the average of 10 hours. Discuss the different estimates. We need to understand, gain knowledge, learn.
Even though gaining knowledge doesn’t end up in a deliverable increment of the software, put it in your sprint or iteration or whatever you call it. The deliverable can be a new or updated JIRA issue, a requirements document, a design note in a wiki. Just make sure that the knowledge isn’t lost, or just stays with the person investigating. It need to be shared.