Estimation of a feature implementation
This is from programmer point of view in order to provide estimation for a faeture implementation:
How can we estimate if a feature implementation is involving modifying the existing code and not clear about the code flow and which would require some code analysis or investgation and don't how many files are getting effected? If that change involves and follows an exiating framework / design, then it requires some time to understand the framework and design.
So where do we estimate this time? Is it really part of estmation? Even we esimate it would be very vague.
What is the best way to estimate in such situations?
Please share your thoughts.
Thanks in advance.
This is not covered by the Scrum Guide.
A practice to cope with the situation you describe is doing a spike. It means that you agree with the PO that you don’t have the overview to estimate a PBI. So you agree to do a time boxed investigation of the issue, in order to be better positioned to estimate. This investigation should be made transparent to everybody as a Sprint Backlog Item.
It's reasonable to conduct a spike investigation as a Product Backlog refinement activity, if that's what it takes to make a PBI understood by the Development Team, and estimatable.
A lot of the time you only need a rough estimate. Ask yourself what value a detailed estimate is worth and how much time is needed to make the estimate.
Look up planing poker and relative estimation as operation for quick estimation.
Some teams also skip estimation totally and treat all PBI as equal in size. That probably works better in Kanban though.
I agree with what Christiaan said: to do a spike - a time boxed investigation of the issue
You can also invest some of your refinement time to take a look on code, see how many things you know/ do not know, and then decide how to approach it e.q. spike or estimate and try to nail it down during sprint