Should you when wanting to prototype a set of tasks beforehand make a task and allocate time aside for this?
Or on the other hand should you reduce the amount of tasks you take for that day/couple of days and inform at a stand up you are prototyping hence the drop off in your velocity?
I'm swaying towards the second one - the material I have on XP has not mentioned this issue.
Thanks.
Yes, a prototype is a task. One approach is called a Spike Solution. It's a real task you really do with a real deliverable.
Do not "mis-state" what you are doing. If you're creating a spike, that's what you're creating. Don't fudge the time. It's real work.
Why Spike? Read about Spike Solution.
Just from the way we do things where I work, we tend to allocate time to it. Seems to work well, as it doesn't count against the developer.
I would have to agree with the answers also given. To just add to the downsides of what you're thinking of doing. If you don't allocate a separate task/time for prototyping something out you may cause the effort put into the prototype (the code) to be used in the final product. The developers may do this to save time in the short term because they are given an unrealistic block of time. This will no doubt cause a negative impact down the road.