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?
asked Feb 4, 2013 at 2:52
-
More on Spikes - scaledagileframework.com/spikes And this one suggests how not to use spikes - leadingagile.com/2014/04/dont-estimate-spikes– Atul KumarCommented Feb 2, 2016 at 6:17
Add a comment
|
3 Answers
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.
-
Consider also that a spike is sometimes used when a development team doesn't feel confident in other valuable Product Backlog Items's in the backlog; having a "research" PBI can be a smokescreen. I tend to encourage teams to include the uncertainty they feel in their estimate for the valuable PBI rather than separating it from the work. This helps to minimize the possibility of waste i.e. the research gets done, but the valuable PBI does not. Commented Jan 4, 2016 at 20:16
-
@aziz-shaikh how do you account for the effort and time of the dev team put into these spikes which are also part of the sprint backlog? Just let the velocity go down? Reduce the teams capacity? Something else? Commented May 5, 2020 at 8:55
-
@bit-pirate Yes, spikes are part of the sprint backlog. Regarding the point of measuring and recording the efforts spent on a Spike, there are two views. One view is that spikes are time-bound but without Story Points. This means that you velocity will go down, however outcome of this spike may help you in picking up velocity in subsequent sprints. Second view is that you assingn Story Points to a spike just like other user stories. Advantage is that your velocity will not drop due to this spike. However, not all spikes are easily estimatable. Do you give higher points or lower? Commented May 5, 2020 at 10:40
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.
answered Feb 4, 2013 at 16:56
-
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? Commented Jun 14, 2013 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.– Todd A. Jacobs ♦Commented Jun 14, 2013 at 13:45
-
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.
