Take the 2-minute tour ×
Project Management Stack Exchange is a question and answer site for project managers. It's 100% free, no registration required.

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?

share|improve this question
add comment

3 Answers 3

up vote 2 down vote accepted

Research stories (called Spikes in Agile terms), should be:

  • used sparingly
  • kept short
  • always be time-boxed

Should we assign a time box (so many hours) for research stories or a regular point estimate?

Regular point estimate cannot be used mainly due to following reasons:

  • story points give out a measure of business value
  • points are used to calculate team's velocity of generating business value
  • spikes are initiated when "there is uncertainty about a story or the team is not sure about how to implement it". When there is already an uncertainty, it becomes unreasonable to estimate it in a planning poker session. It becomes difficult to compare relative sizes of a research work (unknown activity) against a piece of working software, such as creating a shopping cart module (known activity). A spike would help you in reducing risks so that you may better understand / estimate other user stories.

A spike ends when you have achieved the desired results or time is up.

Similarities between story and spike:

  • has acceptance criteria (what means "done" for this spike)
  • added to iteration/sprint backlog
  • findings are discussed or output of spike is demonstrated at end of iteration

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.

share|improve this answer
add comment

TL; DR

Should we assign a time box (so many hours) for research stories or a regular point estimate?

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:

Like other stories, spikes are put in the backlog, estimated, and sized to fit in an iteration...The output of a spike is demonstrable, both to the team and to any other stakeholders...And, like any other story, spikes are accepted by the product owner when the acceptance criteria for the spike have been fulfilled.

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:

  • listed on the appropriate backlogs,
  • counted as work to be pulled into the sprint, and
  • represented in the burn-down chart.

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.

share|improve this answer
    
how do you convert timeboxed spikes to stories? For doing that you must use a conversion ratio which in the end can result with the team counting hours instead of points. The other thing, based on my observations, is that it is hard to predict the outcome of research tasks and people have tendency to spend more time because "I'm so close to find the solution". That's why you need timeboxing. Don't you see a problem here? –  Bartek Kobyłecki Jun 14 '13 at 9:01
    
@BartekKobyłecki You ask interesting question about ideal hours vs. story points, and about time-boxing in general. There are no inherent conflict here, but if you don't understand why then they deserves a longer answer. Please ask these as separate questions. –  CodeGnome Jun 14 '13 at 13:45
    
Did that pm.stackexchange.com/questions/9377/… –  Bartek Kobyłecki Jun 17 '13 at 10:59
add comment

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.

share|improve this answer
add comment

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.