Scrum is often described as a very prescriptive framework despite this is not the case. Take for example the various type of backlog items that we are used to deal with in our favourite backlog visualisation tool. Some work with Epics and User Stories only, others use a mix of Stories and Tasks, others add bugs, improvements or other type of issues. <\/p>\n\n\n\n
I found very useful to introduce and use Spikes with some of my teams. Yet, the scrum guide never explicit, favour or advocate any particular type. In Scrum a unit of increment is called Backlog Item. Yet is up to the team to find the best practices to implement. Scrum is open and incomplete on purpose, to let teams and organisations welcome or borrow concepts from other frameworks, methodologies, techniques.
Today I would like to introduce Spikes. <\/p>\n\n\n\n
Spikes are a type of exploration Enabler Story in Scaled Agile Framework (SAFe). Defined initially in Extreme Programming (XP), they are used to gain the knowledge necessary to reduce the risk of a technical approach<\/strong>, better understand a requirement, or increase the reliability of a story estimate. A spike has a maximum time-box<\/strong> size as the sprint the contains it.<\/p>\n\n\n\n Agile and Lean value facts over speculation.<\/strong> When faced with a question, risk, or uncertainty, Agile Teams conduct small experiments before moving to implementation, rather than speculate about the outcome or jump to a Solution. Sometimes the team is unsure if they can complete the story due to some potential blockers and probably can\u2019t even estimate the story. The Product Owner allocates a little bit of the team\u2019s capacity now, ahead of when the story needs to be delivered, so that when the story comes into the sprint, the team knows what to do.<\/p>\n\n\n\n Here some good use case for when Spikes may be used:<\/p>\n\n\n\n Just like any other ordinary user story, Spikes need fulfil some Acceptance Criteria to obtain the status of done by making sure that the \u201cSpike Story\u201d estimable<\/strong>, demonstrable<\/strong>, and acceptable<\/strong>.<\/p>\n\n\n\n Estimable<\/strong><\/p>\n\n\n\n Like other stories, spikes are put in the backlog. A Spike does not usually receive a Story Point Estimate, but is given a fixed number of hours to be worked on. In any case, the spike should develop just the information sufficient to resolve the uncertainty in being able to identify and size the stories hidden beneath the spike.<\/p>\n\n\n\n Demonstrable<\/strong><\/p>\n\n\n\n The output of a spike is demonstrated to the team in the Sprint Review. This brings visibility to the research and architectural efforts and also helps build collective ownership and shared responsibility for the key decisions that are being taken. Based on the new information, the original question is reframed as a new User Story in a future Sprint.<\/p>\n\n\n\n Acceptable<\/strong><\/p>\n\n\n\n Like any other story, spikes are accepted by the product owner when the acceptance criteria for the spike have been fulfilled.<\/p>\n\n\n\nWhy to use Spike?<\/h3>\n\n\n\n
It is also important that teams plan for and allocate time for getting smarter. <\/strong>Agile teams use the term spike<\/em> to refer to a time-boxed research activity.<\/p>\n\n\n\nWhen to use a Spike?<\/h3>\n\n\n\n
Conduct basic research to familiarise them with a new technology or domain<\/td><\/tr> Some knowledge is needed to decide between different architectures.<\/td><\/tr> Gain confidence in a technical or functional approach, reducing risk and uncertainty.<\/td><\/tr> The team may not have knowledge of a new technology, and spikes may be used for basic research to ensure the feasibility of the new technology (domain or new approach).<\/td><\/tr> Other examples of activities are: research, design, investigation, exploration, prototype, storyboard or some other partial solution to help drive the final results<\/td><\/tr> A story requires to be implemented using a 3rd<\/sup> party library with API that is poorly written and documented.<\/td><\/tr> The story may contain significant technical risk, and the team may have to do some experiments or prototypes to gain confidence in a technological approach that may allow them to commit the user story to some future time-box.<\/td><\/tr> A Proof of Concept (POC) is requested to demonstrate a capability.<\/td><\/tr> A decision needs to be done and documented to rule out some risks.<\/td><\/tr> Estimate new Features and Capabilities to analyse the implied behaviour, providing insight about the approach for splitting them into smaller, quantifiable pieces.<\/td><\/tr> Perform feasibility analysis and other activities that help determine the viability of epics.<\/td><\/tr><\/tbody><\/table><\/figure>\n\n\n\n Shall Spikes have ACs?<\/h3>\n\n\n\n
Takeaways<\/h2>\n\n\n\n