Research Spikes in Agile

In Agile, we have to think about both long-term and short-term goals. The long-term goal is to ensure the customers' needs are translated into release themes. Short-term goals are meant for execution and deliverables. Long-Term thinking translates into release themes, which are split into epics.

A spike in Agile denotes something is not clear to the team. It needs more research to proceed further. In such cases, the recommended approach is to have time-boxed research events called research spikes. Some of the benefits of such an event include:

• Bringing clarity top the solutions
• Helps us to deliver flawlessly
• Cuts down the waste as there will be clarity on solutions for unknown items
• Assures a quality deliverable

Let’s understand the different situations that require research spikes.

Research Spikes

During the iterative implementation phase or before starting the development, there are chances that the team is not clear on some ms such as:

• User needs/Requirements
• Architecture
• Design
• Technology and Tools
• UI Controls
• Existing code

User Needs

In some cases, the user needs are not clear enough for translating them to well-defined requirements. It is suggested to have a requirement spike so that we can come up with these requirements. Instead of starting any development process prematurely, it is always advisable to understand and lay down well-defined requirements in advance. If the requirements are not clear, the estimation could also be negatively affected. All these will be rolled up and becomes quality issues. The better approach to resolve such issues would be to have requirement spikes. To reiterate, the research spikes must be time-boxed.

Architecture

Before starting the project, the team has to decide on the overall architecture of the project. It is important to start it early before bringing the full capacity of the team to work on the project. Here, it is important to have a research spike to decide the high-level architecture for the project. Once the high-level architecture is decided, the detailed level design can be done as part of the sprints.

Design

Before starting the release, it is important to have a high-level design done for the epics. The micro-level work can start in an iterative way based on the high-level design. It does not mean that the high-level design should not change during the iterative process; rather, the high-level design gives a broader approach only. During the implementation, it is ok to change it if the new requirements or detailed analysis demands the change. However, it is important to amend the high-level design and keep it up-to-date.

Technology/Tools

It is important to choose the right technology and tools for a project. We must have a research spike for deciding the technology and the corresponding tools required for the project, which can be done by an individual or a group of members. All the efforts on it, including training new member on using the new tools, will be accounted for and included in a research spike.

UI Controls

The UI design might have some new controls that are not ready out of the box. In such cases, it is not advisable to start the implementation without having knowledge on the UI control. To handle such a scenario, we must assess the requirements far ahead of a sprint and inject a spike in the previous sprint to investigate and do a proof of concept for the same. It will help to understand the estimate required to develop such new UI controls and also implement flawlessly.

Understanding Existing Code

This case is applicable only during new enhancements required for the existing module or project. The team might be new to that module, so pushing the team to start implementation without preparation would add too much risk to the project. It is important to make sure the team is up-to-date with module knowledge. It will help the team to estimate the new enhancements accurately. To make the team aware of the existing code, it is important to have a research spike to study the existing code.