# How to estimate a timeboxed spike using story points?

So my team and I are quite new to Scrum and today moved from estimating in Ideal Hours to Story Points. All seems sound rationale, BUT with timeboxed activities. Here is the case, we have an extremelly complex User Story that needs a spike so to explore underlying technical unknowns. With Ideal Hours it would be easy: timebox it to one ideal day (8 ideal hours). Now we want to account the exploratory work towards our velocity. So, the pressing question is how do we give Story Points to a timeboxed activity? Constraint: we do not know how to translate this 1 ideal day into Story Points because our historical data is badly collected and does not reflect reality.

• How long are your sprints? After a reasonable number of them, the fluctuations should average out. – Matthew Flynn Feb 7 '12 at 4:58
• Our sprints are 2 weeks long. Though, our team capacity varies a lot (random annual leaves taken at odd days). Therefore, expecting things to average out would require too many sprints to be accomplished – Pomario Feb 7 '12 at 10:44

Personal opinion here, but firstly I prefer to think in terms of complexity rather than story points. I think story points can mean different things to different people so there can be a point (no pun intended!) of confusion when talking about them and estimating based on them.

Secondly, I would not worry about estimating a spike. I would just give it some time (as per your 8 hours) and see what pops out the other end. I don't think you can assign complexity to it because the idea is to find out what the complexity of it is. Otherwise you would not need it.

Thirdly, I would not be including spikes in velocity calculations. Simply because I would expect every spike to be different and I don't necessarily expect a result from a spike. So I think including that time could distort your velocity. I would just write that time off the same way I would write off time if a developer is away sick.

Personal Opinion:

I don't think you should assign points to a spike. The reason for a spike is you cannot poker plan stories because of some unknowns.

1. You realize you need a spike because you cannot estimate something in terms of story points
2. Try to find out what you can within one day (or 1/2 day).
3. At end of day (or 1/2 day) determine if you are ready to estimate. If not goto 2.

This will not reflect in your velocity, but you can also have an "average spike time" as a additional measure. This will serve as a future estimator if you need a spike.

we want to account the exploratory work towards our velocity.

Why? Velocity is not for exploratory work but for gauging how much more iterations are needed before you can ship the release or if you fixed number of iteration, it is for gauging how much work you can do in the given time

So, the pressing question is how do we give Story Points to a timeboxed activity?

you don't. You do time boxed activity i.e. spike, (1) to give story points to the actual user story, that you will do later in a sprint, and (2) to break it if it seems complex/big.

we do not know how to translate this 1 ideal day into Story Points because our historical data is badly collected and does not reflect reality.

no one that I know who understands scrums does this.. In real project you may spend, let say, 15 hours on a 3 point story and 9 hours on a 5 point story i.e. more time on less complex story. So what does this mean? it means that although most 5 point stories will have more hours put to them as compared to 3 hours but there can be cases, lets say 25% chance, when a 3 point story can take more time than the mean-time spent on a typical 5 hour story.

Once you have historical data collected it can be like on 3 point stories you have spent between 3 to 18 hours with mean around 4.5 hours. and on 5 point stories you have spent between 3 to 14 hours with mean around 10 hours..

• Where I worked, it was more like a 50% chance 3 was longer than 5. They are so close I often pushed to remove some number. IMO, I wanted to drop the "standard" numbers and have 1,5,13,20,40. How often do you really need the difference in 1 and 2? 2 and 3? even 8 was hit or miss for us. – Joe Feb 13 '12 at 19:11