Spikes How Does Your Team Handle Them

#1

Wanted to get the communities takes on how to adress spikes with their teams. This was a debate at Scrum master COP. I look at it from the option two point of view most of the time.

  1.   Spikes should be planned for the tasks and hours, and those hours subtracted from the sprint capacity.  The spike itself should not be given a point value.  Only give point values to stories that result in deployable value.  So you do a spike to learn enough to write the story, you point the story but not the spike.

  2.   Treat spikes the same as other stories, plan the task hours, and be sure the size of the spike (points) represents a similar size to stories taking similar effort.

Thanks
James

#2

Hi

I always use Spikes to investigate a new language or how to deal with unknown because of that with my team members have never treated the Spikes as usual user stories. In fact, we never split the Spikes in tasks and assign hours.

For me, Spikes are useful when you have to deal with something unknown (for business or technical reasons) for the team. Furthermore, you shouldn’t invest more than a day or two dealing with Spikes except the PO considers the Spike as critical to delver value in the Sprint.

I hope my response will be useful for you.

If you want to dig more deeply don’t hesitate to reach me at Skype (metlucero).

Regards,

Mario

#3

In my experience, I generally see spikes used in place of documentation or as coercion to an existing dysfunction.

e.g., “the stakeholders want to know what the design will look like first, so we’ll do a research spike to provide them a couple documented mockups.”

Unknowns happen all the time for a team. When an unknown requires a “spike,” I ask teams to consider uncovering the knowledge with actual software… it doesn’t need to be production ready, but there is no better way to learn about the work… and working software is the best feedback loop possible.

After all, that’s a core agile value: working software over comprehensive documentation.

#4

I honest to god just had this same conversation with a team in the last hour, suggesting the exact same thing. Creepy.

#5

I think either would be fine actually as long as the team is consistent and knows why it’s using either of the techniques. A few other thoughts:

  • tasks and hours are something that many teams get away from, so using them for spikes may go away as the team matures.
  • SAFe prescribes that everything gets story points…which I sort of agree with. It keeps it simple. Short of not using points at all (which I’m really becoming a fan of lately), I think just avoiding all the conversations around “this isn’t working software, so we shouldn’t point it” and just pointing everything makes things easier all around.
  • I haven’t had a lot of luck being super accurate with hours and capacity. In my experience, it’s a helpful tool, but I’ve found that the team’s gut feel of how much work to take on is just as accurate…especially after a few sprints.
#6

I’ve had this debate with many scrum master. I’d prefer just posting all the info here, but it’s easier to put a link to where I wrote about it. Pardon the shameful plug.

#7

I prefer option 2, because the team is spending some of it’s time doing the Spike and it does actually have value. Aside from that, the most important point to remember is that it is time-boxed (no more than 2 days) and needs good Acceptance Criteria, to know when you’ve achieved what you set out to do