One of the key elements of working with agile frameworks is the ability to create transparency by visualizing the work taken on by the team. In well-known settings, the team refines work to a state where it is ready to be worked on. This is typically done by taking a reasonable-sized improvement request to the product and demystifying the scope while figuring out what work needs to be done in the team to deliver value to the customer. Being able to deliver an increment of value iteratively and incremental is essential. If we lose the transparency in the team, it will be impossible to collaborate when progress stagnates and impossible to identify and resolve impediments.
Not all teams are in a situation where requests can be quantified and broken down into specific tasks that eventually leads to closing the request. Examples of such requests could be bug fixing, experiments with new technology, and migration. This type of work is labeled as spikes. The concept of spikes originates from Extreme Programming (XP) by Kent Beck back in 1996. In XP, a spike is a very simple program to explore potential solutions and reduce the risk of a technical problem. A spike is often defined by a hypothesis, e.g., “Using augmented reality glasses to visualize 3D models will reduce time spent on maintenance” or “Migrating our codebase to python will enable automated testing.”