Spike user stories
- We're just starting scrum here. We're all  reading like scrum and
user story books like mad.
Where we identify a story that we (the devs) don't know enough to
estimate we ask the customer (product manager) to have a spike to learn
enough to then estimate the full story.
In some cases this is to investigate a new 3rd party SDK and in others
it might be to do performance profiling of our app to then estimates
stories like (improve the X part of the product so it is comparable with
Unfortunately the software manager (who is currently a kind of scrum
master master) says "No, sprint deliverables must be working, tested,
Is he right? If so what should we be doing? I'm a bit lost and our scrum
masters (including the software manager) don't get their scrum master
training until September.
1] obviously not all, there the usual bunch of people who basically
- Hello Marco, thanks for sharing your thoughts. On Monday, August 21,
2006, at 9:26:38 AM, you wrote:
>> Nonetheless, I like a story / feature burndown at the project level,Yes. In my opinion, this is a sure sign that the story sizes are
> I agree with you if you managed to have fairly similar stories size/effort
> wise but when you have stories of different size/effort a story/feature
> burndown is misleading because it doesn't show you how much effort you
> still need to put into the project if you want to deliver them all.
too widely varying, and it's the thing to fix. Failing that, story
points or some other pure estimate works well.
> I spend at least one day every week discussing this same issue with myYes, but ... when you have 4 stories this actually has an effect.
> current customer's managers. They like the total effort based
> burnup/burndown but at the same time want a chart based on number of
> stories and give to the latter one more weight. But they communicate
> different messages! Example:
> - 10 stories for the release of product X
> - 5 of them have an estimate of 1 WUYU (whatever unit you use...)
> - 5 of them have an estimate of 3 WUYU
> - for various reason you cannot/don't want to split the bigger one down
> - 1 of the 3 WUYU stories yet to be done
> an effort based chart will show you that you still have 3 WUYU to do and
> you can use your velocity to commit to a date while a story/feature chart
> will show you only that you still have 1 story to do without an indication
> of what that means.
When you have 40 or 100, it turns out that the count tracks the work
units just fine. Law of large numbers hits quite early. Try it
> You can have situations in which people are worried because you still haveYes. I prefer to work with approximately two stories per programmer
> 4 stories to do not considering they are small, 1 WUYU stories and, at the
> same time, people not worried at all if you still have 2 story to do even
> if it is a 3 WUYU one.
per week. In that case ... this becomes a non issue.
Thus my "advice" is to use story count ... and do what has to be
done to make it work, which usually means many stories of
approximately the same size.
Find the simple path to what works and follow it,
always looking for a simpler path. -- Patrick D. Smith