Should I include the research time in a agile task? [duplicate]

Question

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.

Answer 1

The word "research" is indeed being overused in agile. The word can be broken down into:

1. 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.
2. 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".
3. make a single implementation attempt in order to validate / explore a semi-committed implementation choice.
   • This is a "spike".
4. 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.

Answer 2

Ken Rubin answered this at a training workshop for us. His advice was to either use a research spike or to use a story task for the training. In your case, you know what product that you are using, and you just need to account for the learning curve. I would recommend a learning task. I remember during the class someone asked if we could just create a story like "As a software engineer, I want to learn NLog...." This was answered with a firm "No" because the story does not provide business value, but as a team you are free to create the tasks needed to accomplish a story. My team recently needed to learn Elastic Search and we did just this.

Ken Rubin elaborates more in the "PBI Type: Knowledge Acquisition" section here http://www.innolution.com/blog/demystifying-product-backlog-concepts