In our Scrum team, when there is uncertainty about a story or the team is not sure about how to implement it, we take up a research story first. Based on the findings of this research story, we are able to estimate the base story better. Should we assign a time box (so many hours) for research stories or a regular point estimate?
Research stories (called Spikes in Agile terms), should be:
Regular point estimate cannot be used mainly due to following reasons:
A spike ends when you have achieved the desired results or time is up.
Similarities between story and spike:
Difference between story and spike:
Spike does not deliver shippable product (business value). As Agile Principles states, Working software is the primary measure of progress, completion of a spike does not directly create a working software.
You should do both. A spike (or "spiked story") requires both a time-box and a level-of-effort estimate, and is always counted as work.
Spikes Are Just Special User Stories
As one source states:
The main distinction is that a spiked story is designed to reduce the cone of uncertainty rather than deliver a shippable increment. However, all the other requirements of good user stories and framework processes apply.
Why Spikes Should Be Estimated with Story Points
Scrum and XP are all about time-boxing; it is therefore axiomatic that all processes within these frameworks need to have a finite duration. However, the reason for assigning story points is slightly less obvious.
The CodeGnome agile motto is No invisible work, ever. Since a spike consumes time and resources within a sprint, it is essential that the effort expended on the spike is made fully-visible to the project. The way to do that within Scrum is to ensure that the spike is:
While some people may argue that assigning story points to spikes will skew velocity, this is a misunderstanding of the velocity metric. Velocity doesn't measure features, it measures capacity. Specifically, velocity is a trailing average used to estimate the team's available capacity for future sprints.
It is up to the Product Owner to prioritize that capacity. Balancing the delivery of shippable features against other (perhaps less-tangible) project requirements is the province of the Product Owner; tracking and estimating all project-related effort on the Product Backlog is the essential mechanism to express that balance visibly within the project.
This is a great question, since this comes up for us a lot, too.
We haven't done anything specific for this before, but I think you're right about timeboxing it. X amount of hours, and then reconvene. If they're "almost there" in finding answers, maybe make a new story for round 2 of research and so on.