hello everyone this is karen for my phone welcome back to my channel today we will be talking about
spikes in a scrum team so if this is your first time here very quickly you're very very welcome
just so you know what we talk about every week agile scrum project management product development
how to continuously improve and we just share ideas around these um career paths so if you're
interested and um want to stay in sync with our weekly upload please go ahead and turn on that
subscription button switch on the notification bell so that you will never miss out on any of our
materials and if you are returning viewer a returning subscriber
i salute you you are awesome you are just awesome it's because of you that we've come
this far and i appreciate you so much now thank you so much and let's go straight into our topic
what is spike in agile um project management um scrum team so there's been a lot of conversation
going on around the same spike topic so i thought i should just come on here and share my opinion
now this is what i think i need you to see spike as research work you know there are different
categories of work items in the product backlog that's why we call it product backlog items which
means that in a product backlog we are not expected to only have user stories you see
user story is just a type of work item the same as spike the same as defects the same as um task
so those are just some of the few categories of um different work items out of so many others
now specifically on spike i need you to see spike as research work
usually when does spike come into play spike usually comes into play when
team members are um discussing on a specific ask or want to call it requirements and so far they
are not able to truly understand what it takes to be able to accomplish that work within us friends
and they need to gather more information or more empirical data so that at least it will
raise their level of confidence um in a way that once they commit or once they are able
to pull in that work item into the sprint as a user story at least they have some level of um
certainty that they will be able to accomplish that work you see so in that case they would want
to do more research more findings um gather more information that will enable them to be able to
work on that user story and accomplish it in a way that will deliver a value to the customers
so that kind of item determine it as spike so in summary or in a nutshell i need you to see spike
as research work that category of work that a team member will pick in order to do more investigation
do more findings and zeke to gather more insight on how to go about this what it really takes in
order to be able to successfully accomplish the work that we deliver results to the customer
so that in my opinion is what spy is spike is not a user story sometimes i hear team
members you know even scrum masters agile coaches they will call something a spike user story
it is a spike it's not a user story a user story is a story that's why it's one category you
cannot say a spike user story now a spike is a spike a user story it's a user story
and i think that um to me i'm very particular about calling things the right way using the
right terms to call things just the way they are and because i have noticed that for some reasons
when people miss call names um things names that they truly are not it um it just brings some
confusion in their head and india they just have misconception so i'm very very particular when it
comes to calling things the right names you see so spike is a spike a spike is not a user story spike
no oh it's five is not a user story it is just a form or a type of work item where the goal of that
work item is to do research to gather more insight to be able to execute the user story that will be
created after the findings have been achieved you see so now in my experience this is how it works
let's say we are currently discussing on one ask that customer has asked and then the cost
of having a conversation i'm talking about the developers you know they realize that oh
they don't know everything so they don't know they don't they're not necessarily supposed to
know everything anyway so but they don't have enough information that they can at least get
going on this work and deliver result value to the customers so they would go ahead and create a kind
of work item that they call it spike now once they create this work item a team member can assign
themselves to this work item and say okay i will go ahead and do these findings on what we really
need to be able to deliver results to the customer and then now they will just time box it and once
the time box if they get going in their spring so they pull it into the springs though they pull it
into the springs they get going with the work and once that team member is able to gather the
information that they've been looking for or find out what they've been looking for they come now
and create a user story to be able to execute so that the customer can get value you see so that is
in my opinion that is what a spike is so a spike is not a used story no a spike is just a form of
work item which is um which which the goal of it is to gather more information that will enable
them to generate a user story that is valuable to the customer now this is the biggest twist
these is the biggest challenge that i have experienced and i see some scrum masters
team members just getting the whole thing mixed up and it is very very critical before i address this
please stay tuned right up to the end because it's very important i just want to first remind you
that um we have great mentoring programs to help um upcoming or aspiring scrum masters to be able
to get going into the field landing the job and be very effective on the job so if you're looking to
um excel in this career path you're not sure how to go about it you don't have any clear direction
please reach out to us we'll be more than happy to help you we have great success story it's not even
something that um we are arguing about ours our results speaks for themselves visit our website
you will see our reviews there go on google you will see our reviews there you see reach out to
us who will be more than glad to walk with you to the very end our program is very supportive it's
just not all about agile it's deeper than that the way a program is structured it's a family
that that um strives to help each other succeed and grow so reach child also be so glad to help
you if you're just starting or you're just looking to transition into this career path you don't have
any knowledge whatsoever contact us our level one program is designed for that to help you close the
gap um to acquire the theoretical understanding of the concept and then you go get certified once
you get certified and then you can move up to a level two program to help mentor you and coach you
towards learning the job the same for those who are already on the ground as professional scrub
masters as our coaches release train engineers delivery managers if you're struggling with your
job you're you're just not able to get it and you see that you're not adding value to your
organization as a true agile practitioner trust me there is no way you can feel good about yourself
if you are in that situation reach out to us we have an excellent program that work with you to
be very valuable in your organization you'll be adding quantifiable results in your organization
they can feel your impact if you're able to join our program we will
be glad to work with you through this journey so let's go back to our topic now this confusion
that i've seen happens a lot in this agile space is i see some teams estimating spikes
they will use story pointing and then they say the spike is five the spike is three the
spike is two the spike is eight okay if you're able to estimate it then why is there a spike
if you if you know enough to be able to estimate it then why is it a spike because
the only reason why you're spiking is because you don't know enough to be able to deliver
the value or accomplish the work that will deliver value to the customers if you know enough to be
able to estimate the work then why are you spiking it it should be a user story if you think you know
that well or that much to be able to give it an estimate and then it should be a user story
not a spike so in my opinion if you think that you don't know enough to be able to do this user story
and deliver value to the customers then it means that you shouldn't be able to estimate it as well
so i would not encourage teams to estimate spikes again to each their own organizations
do it differently but i don't see that as a good practice at all i don't see that as a good
practice yes at the same time i understand you need to account for the work that you're doing
that is why it's very important to also plan capacity capacity planning also is very helpful
so that you can use your capacity planning you can use your capacity plan to be able to account for
the work that you have committed to or the time that you have committed to to to accomplishing
the spike you know so in my opinion i think that we should be time boxing spike i mean this is a
self-managing and self-organizing team it's not as safe we want to micro your performance is measured
by the number of story points to accomplish then you're afraid and that's the reason why you want
to spike you want to estimate spikes in the first place you see i'll say that as an issue
so bring your spike into the spring just time box it a sprint is a two-week sprint right for example
so you can say that okay let's bring this and start doing the work and once we are able so the
cap is the two week sprints but if you are able to uh discover what you're looking for it's okay even
if you're able to discover what you're looking for just after two days from the start of the sprint
great you can now go and generate a user story for that spike and then go ahead and estimate that
user story you see so you shouldn't be estimating spike because you don't know enough that is why
you're spiking that work item in the first place so to account for the time again in summary
it's important to do your capacity planning so that you can account for the time or track the
time that you have spent on that work so that in the future you may use that to you know
future estimates or discussion use that to to to improve you know yeah so that would be my
opinion around um this pie conversation i don't think we should be estimating spike i don't think
we should be giving any points or spike because you don't know enough to be able to estimate it
and that's the reason why it's made in the first place so that you can have some form of accuracy
to be predictable you see so just um time box it get the the work done once you discover what
you're looking for go ahead and generate a user story for it and then at that point you can now
estimate it and you get going everyone is happy thank you so much and hope to talk to you next bye