Skip to main content

Estimation of a feature implementation

Last post 04:07 pm February 10, 2016 by Andrzej Zińczuk
5 replies
09:19 am March 27, 2015

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.

12:22 pm March 27, 2015

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.

01:12 pm March 27, 2015

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.

04:29 pm March 30, 2015

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.

04:24 am March 31, 2015

I agree with what Christiaan said: to do a spike - a time boxed investigation of the issue

04:07 pm February 10, 2016

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

By posting on our forums you are agreeing to our Terms of Use.

Please note that the first and last name from your member profile will be displayed next to any topic or comment you post on the forums. For privacy concerns, we cannot allow you to post email addresses. All user-submitted content on our Forums may be subject to deletion if it is found to be in violation of our Terms of Use. does not endorse user-submitted content or the content of links to any third-party websites.

Terms of Use may, at its discretion, remove any post that it deems unsuitable for these forums. Unsuitable post content includes, but is not limited to, Professional-level assessment questions and answers, profanity, insults, racism or sexually explicit content. Using our forum as a platform for the marketing and solicitation of products or services is also prohibited. Forum members who post content deemed unsuitable by may have their access revoked at any time, without warning. may, but is not obliged to, monitor submissions.