Requirements in Agile
Introduction
On Agile projects, requirements are communicated through user stories, spikes, epics, and bugs. These requirements are typically captured in a product backlog and prioritized by the product owner.
User stories are covered in detail here.
Spikes
A spike is an investigation into a user story or a technical issue. It is used to answer a question or gather information that is needed to estimate the effort required to implement a user story. This might include researching a new technology, prototyping a solution, or investigating a bug.
Unlike user stories, spikes are time-boxed and are not intended to deliver a shippable product increment.
Some possible goals for a spike include:
- Gain confidence in a technical or functional approach in order reduce risk and uncertainty.
- Perform feasibility analysis to determine if an epic is viable.
- Estimate a proposed feature in order to provide insight into the best approach, to split the feature into smaller pieces, and to accurately estimate the work required.
- Conduct basic research in order to become more familiar with some new technology or domain.
Types of Spikes
There are two types of spikes: technical spikes and functional spikes.
- Technical Spikes: These spikes are used to investigate technical issues. They might be used to determine the best way to integrate a new library or to investigate a performance issue.
- Functional Spikes: These spikes are used to investigate the details of a feature and its risks. For example, a functional spike might be used to determine the best way to implement a complex user interface or to investigate the feasibility of a new feature.
Creating Spikes from User Stories
Spikes are often created in response to a user story that has a high level of uncertainty. If there are a lot of unknowns, it can be difficult to estimate the effort required to implement the user story. In this case, a spike can be created to investigate the unknowns and provide more information.
For example, if we have a user story such as:
As a marketplace seller I want to see my monthly sales as a histogram by dollar amount so that I can quickly understand the purchasing habits of my customers.
This story might lead to one or more spikes to clarify the work required to implement the feature. For example, we might have a spike to prototype the histogram display and get user feedback on the style and layout. Perhaps we need determine how long it takes to query the sales data and understand the bandwidth or performance requirements.
It is also possible that this user story would lead to no spikes at all. If the team is confident in their ability to implement the feature, they might estimate the story without any spikes. Perhaps we already have a histogram component that we can reuse, or we have implemented similar features in the past. Perhaps we have a senior engineer on the team who has experience with the performance characteristics of the system.
Generally speaking, the more expertise the team has in a particular area, the less likely they are to need spikes to estimate the work required.
Guidelines for Spikes
- Time-boxed: Spikes should be time-boxed. The goal of a spike is to gather information, not to deliver a shippable product increment. The time-box should be long enough to gather the information needed to estimate the user story, but not so long that it becomes a project in itself.
- Quantifiable, demonstrable results: The spike should have a clear goal and a clear end point. At the end of the spike, the team should have gathered enough information to estimate the user story or make a decision about how to proceed. The output of a spike should be knowledge that can be shared with the team.
- Use sparingly: Spikes do not contribute directly to the product increment, so they should be used sparingly. If the team is using spikes to investigate every user story, it may be a sign that the team needs more expertise in a particular area or that the user stories are not well-defined.
Epics
An epic is a collection of user stories with some unifying objective. Epics are used to group related user stories together and to provide a higher-level view of the work that needs to be done. They are generally larger than user stories and may span multiple sprints. This might be a complex feature or a set of interdependent features.
Bug Reports
The purpose of a bug report is to document an issue or software defect and give the development team enough information to reproduce and fix the issue. The best bug reports are concise and to the point. Avoid including confusing spreadsheets, long text descriptions, or irrelevant information. Short and information dense will be the most helpful.
Make sure to include enough information that the developers can clearly understand the issue's importance and impact so that they can prioritize it accordingly.
Bug Report Template
When creating a bug report, include the following information:
- Title: A short, descriptive title that summarizes the issue.
- Environment: The environment in which the bug was found (e.g., browser, operating system, device, staging vs production).
- Steps to Reproduce: A list of steps that can be followed to reproduce the bug. Be as specific as possible.
- Expected Behavior: A description of what should happen when the steps are followed.
- Actual Behavior: A description of what actually happens when the steps are followed.
- Visual Proof: Screenshots, videos, or other visual proof of the bug.
- Severity: How serious is the impact on the user or the system?
Bug Severity Levels
When reporting a bug, it is important to include the severity level. This helps the development team prioritize the bug and determine how quickly it needs to be fixed. This severity needs to be accurate and not exaggerated. It is shockingly common for bug severity to be exaggerated, leading to a loss of trust prioritization problems.
I once worked with a VP who always categorized any issues he found as "critical", regardless of the actual impact. This disrupted several sprints as we dropped everything to address his "critical" issues. Eventually, the team learned to ignore his severity ratings, and he lost the ability to influence the team's priorities.
Here are some common severity levels:
- Critical (P1): The bug causes a system crash, data loss, or other severe problem that makes the system unusable.
- High (P2): The bug causes a major problem that severely impacts the user experience or functionality. The system is still usable, but with significant limitations.
- Medium (P3): The bug negatively impacts the user experience or functionality, but there are workarounds or the impact is minor. This might also apply when the broken feature is rarely used.
- Low (P4): Everything else. This might include cosmetic issues, typos, or other minor problems that do not significantly impact the user experience.
Assigning the correct severity level helps the team to maintain a balance between fixing bugs and delivering new features. If everything is a critical bug, the team will be constantly firefighting and will not be able to make progress on new features.