Sometimes a user story is generated that cannot be well estimated until the development team does some actual work to resolve a technical question or a design problem. To begin, I’ll answer the question of “What is a spike?” by accepting the definition from : SpikeĪ task aimed at answering a question or gathering information, rather than at producing shippable product. And perhaps the feedback from this article will further evolve my thinking on the subject. But I did gain from hearing several arguments for how spikes could be used more effectively if they were to be sized with story points. While several colleagues came with an abundance of material to support their particular position, no one addressed the points I raised. My position: Estimating spikes with story points is a vanity metric and teams are better served with time-boxed spikes that are unsized. So after doing a little research on current thinking, I updated an old set of slides and presented my position to a group of scrum masters to set the stage for a conversation. I’ve experienced a lot of different projects since last revisiting my thinking on this topic. I recently did this with the practice of sizing spikes with story points.
Maybe even find if it can be used in a new way. Every once in a while it’s good to take a tool out of its box and find out if it’s still fit for purpose.
0 kommentar(er)
