The answer to the first part of your question can only be answered by the team. There is no such things as "per standards" in Scrum. How many spikes can we accommodate in a sprint as per standards and what will be the outcome in sprint review meetings. In fact they tend to get much better results when instead of tasking out a Spike they all swarm on the effort. Since a Spike is more like a research effort it is near impossible to task them out and most of my teams see no reason to do so. I encourage the time-box to be less than 4 hours and is worked in one block of time instead of spreading the work out throughout the Sprint. Given my interpretation I coach that a Spike be time-boxed in hours and not estimated. User Stories, Spikes, etc are taken from other agile practices. That is the way I interpret spikes but remember that the Scrum Guide never mentions how Product Backlog Items are defined. My understanding is that Spike is created to address the question but not to provide the potential shippable product. Do we need to have drilled down tasks for spikes ?ģ. This user story had only development tasks and the PO advised not to have QA Task as this will be sliced down to ready item for next grooming session and only developers estimated this user story. One thing I observed was there were couple of User stories created as spikes with a user problem and the acceptance criteria talks about the technical approach. We are having backlog grooming session for future sprint on 2nd week of current sprint where we do discuss on the stories which the PO brings in after discussion with stakeholder parties. We are scaled agile team, where one team sits in Russia and other two in US & India respectively.
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |