I was given a project for a logging framework. It has many tasks of course. One of them is Create a Class that can Log to a nLog Target(6 hours). However I am not familiar with Nlog. I guess that I need a lot of google research time. I am not sure whether should I include the research time. If so then six hours is obvious not enough. I am confused the task time, is it the pure coding time? EDIT:We don't have a research spike in the process but we have two hours for research NLog API. 
Should I include the research time in a agile task?
agile
The word research is indeed being overused in agile. The word can be broken down into: learning, or reading documentation, or learning-from-trying. This is just learning.This is not meant to belittle the time needed for learning. It can take a long time, e.g. weeks to months, but the learning process should be considered and included into the time estimate.It can take a short time - if the team has already used something similar before.broadly survey from a large number of options, gathering basic information and characteristics (specs, limitations) about each, but avoiding actual coding (i.e. without committing to any). This was previously called research but should have been called survey.make a single implementation attempt in order to validate / explore a semi-committed implementation choice.This is a spike.make repeated implementation attempts in order to competitively select one or more implementation choices, but with the understanding that the final implementation will only benefit from one of a few such choices.This is a true research.Coding time spent on inferior choices (which are not known in the beginning but are gradually revealed during the multiple attempts) do not contribute to the business value.Because of this, it is advised to try ferret out and eliminate inferior choices as early as possible. However, one needs to keep in mind the possibility that an earlier determination of inferiority may change as more information becomes available.In your situation, it belongs to the first case (learning), therefore:The 6 hours you mentioned is the planned time for all of the work needed to create a task that can ...Any learning (as explained in the first case) are included in this 6 hours.It is possible that it will take more than 6 hours. Task estimates are estimates. When estimates are exceeded, the scrummaster will know that in the next day's meeting, and generally the team will be allowed to continue to work on it. Estimates are not deadlines. The word time-box in Scrum also has multiple meanings.Within a single sprint, it is not a deadline. When a task took more than the estimates, the team can discuss it, either as a follow-up to the daily stand-up, or perhaps during the sprint retrospective. The purpose of such discussion is that if a task took much more than the estimate, the team has implicitly discovered or experienced something new - something that will slow down the task, which was not considered when the original estimate was made.It may be that the task is indeed more difficult than originally planned.Whatever that is, such new information need to be incorporated into future time estimates. The dissemination of such experience is the reason for the discussion.The word time-box, as used here, is to make sure this discussion happens, that will not go unnoticed.A time-box is a deadline only when decided so by the ultimate decision maker, that is, when the stakeholder has the consensus that the feature needs to be dropped because it appears to be unimplementable given the current circumstances and resources.Disclaimers.This is my personal opinion.I don't practice any agile methodology.My opinion may have many inaccuracies, mistakes and misunderstandings from the point-of-view of the scrum or agile methodology.I don't have any certificates, trainings, or credentials in relation to anything.I am personally frustrated by the overuse of the word research, because in the rare case that a person claiming to do research for the case one (learning something), may impede a person actually doing research for the case four (actually inventing some new algorithms), by weakening and belittling the claims in the face of project managers or agile practitioners.