Due to the Russian invasion of Ukraine, we have paused all purchases and training in and from Russia.
How to integrate a Spike with Scrum
I’m curious how Spikes are normally integrated with Scrum.
Let’s say you have a new development team which consist of external highly skilled developers. None of them has ever worked in your organisation/project so when it comes to knowledge of legacy systems, coding standards, used frameworks, libraries, tooling etc. it’s all new.
Now imagine it’s Monday and the team are gathered for their first SPM where the PO does his normal routine which is explained in high level what (s)he wants. At this point 10 User Stories has been explained and the team fully understands what the PO (functionally) wants.
Now comes the problem. Knowing what the PO wants doesn’t automatically means that the team knows how it’s going to be implemented. As I said the development team consist of new developer consultants so there is currently no technical context yet. So SPM 1 just ended and the team starts SPM 2. I can imagine at this point, during the meeting, all developers will be like “I have no idea which tasks are needed to implement this item, because I don’t know what can and cannot be used within this organisation. To be it even more difficult, the project isn’t really a demarcated project, its actually a maintenance/ new feature project. So it’s mainly fixing and improving features in existing MULTIPLE large systems, which makes the scope extremely wide. Due to this, every User Story has its complexity as in it can be in different systems.
Now I’ve heard that Spike is a good solution is clear up uncertainties, but how does this work? Let’s say the first 10 User Stories has the highest priority.
1) Do you create a ‘Spike Story’ for every User Story? As I said, every User Story can be a fix/improvement in different systems. (lots of uncertainties)
2) Is it common to take both the ‘Spike Story’ and its actual User Story in the Sprint so that if the Spike is finish, the team can estimate and work on the User Story?
3) Should Spike Stories be estimated?
4) Or is it like the first Sprint the team stuff it full with Spike Stories so that in the 2nd Sprint they can come up with a couple of estimations and start implementing it? While at the same time working in Spikes for the next Sprint?
How is Spike normally integrated with Scrum?
To reach Sprint Planning 2, the team must have had enough confidence (in Sprint Planning 1) to commit to a Sprint Goal, and to have estimated (e.g. relatively sized) each requirement. In other words, they must have expressed reasonable confidence in their ability to deliver a potentially releasable increment, even though the technical context is unknown to them.
Assuming that's all the case, then so far so good.
Now you have a choice. I'd agree that the authoring of spike stories is reasonable, as long as they are kept off the Product Backlog. The team would have to introduce them directly into their own Sprint Backlog since they are part of their own plan for delivery, and do not (in themselves) represent product value. However, this is a controversial practice and some authorities do not recognize this type of story as a valid construct at all.
Another option is (in Sprint Planning 2) to identify "spike tasks", each of which will anchor the other tasks for that story into an appropriate technical context. That's probably a more defensible choice. Task identification is generally accepted as being entirely at the development team's discretion.
I doubt on the estimation done by team in SPM 1 if they don't know how to implement the story. I can understand there can be some %age of uncertainties. Assuming this is a new project/product and all team members are new, I don't mind doing spikes in first sprint for getting the estimation for future sprints however it should come from the team not PO. As a PO I would put a story for the required feature and if team feels that they need a spike before start working on that feature then PO should create a spike. It doesn't make sense to have the spike and actual feature in the same sprint. For spike I generally put in the acceptance criteria -
Create/update PBIs for feature X
Put estimation for all PBIs related to feature X
A Spike is a timebox for the Dev Team to get enough knowledge for estimating a story. The value for the product owner is, that he can then do his release planning, which would otherwise not be possible. During a Spike, the Dev Team can create a functional prototype, even neglecting the DoD - but it has to throw it away afterwards. It's just for learning, not for creating product value.
I usually do not have Spikes with experienced teams. With unexperienced teams they do have some value, especially in contexts where Agility is not yet fully understood and the wish for precise estimates is high.
Usually, the Product Owner does not carry around Spikes in his Backlog. Only when during the Sprint preparation meeting the Team can't estimate something and asks for a Spike, he might negotiate the timebox, take it on the backlog, and only keep it there to the next Sprint Planning meeting.
While this is a controversial practice, I have seen situations where this tool was benefitial. Just make sure the Scrum rules aren't broken!
Thanks for your response.
A question regarding the following:
A Spike is a timebox for the Dev Team to get enough knowledge for estimating a story.
Lets say that the project have 20 stories and the team isn't confident enough to estimate any of them due to the lack of domain knowledge and the framework, libraries, tools used within the organisation. As i said, the developers are All external (experience) consultants.
What would you advise when it comes to using Spikes? Do a Spike for every story? Is it common to do a Spike Story first and than immediately after that the actual story wothin the same sprint?
Or do they always need to be seperated?
We have had cases where experienced developers only needed 1 or 2 days to learn something. From there, they were able to jump right into the feature story. All within the timebox of our sprint.
My only point is that one should not constrain spikes and stories to separate sprints. There are real world cases where it simply makes sense.