 | Tasks, Bugs, Tests & Spikes |
There are also tasks or to-do items that don’t constitute a story but still need to be tackled systematically. Whereas a Story must be written in non-technical terms from the user’s perspective, these items are written by and for the Development Team, often in a “to-do list” format.
For many/most teams, these items allow them to break down an individual story into actionable items that they can tackle systematically.
Tasks vs Bugs
What is the difference? For most teams and in most scrum-specific software, very little. A “task” indicates something to be done, perhaps, while a bug indicates something that needs to be re-done. No matter what the label, a task and a bug would be represented on a sprint backlog in a very similar fashion (probably only differing in color and icon). Their features and functionalities would be almost identical. If anything, the “done” setting might be labeled differently (“complete” vs “resolved”). For practical purposes, however, they are very, very similar.
Tests
Like tasks and bugs, there is nothing unique about a test item. It is worth discussing separately only as a reminder that
- Testing is to be done throughout a sprint; not just at the end
- In Scrum, testing is generically assigned to the dev team
Why is this important? There is a tendency for programmers to see the end of the sprint as their deadline for stories and testers to think of their roles as distinct from the rest of the team. This leads to “bottlenecks,” often at the end of the sprint. It also puts undue pressure on testers and creates a risk of shoddy, rushed work. Scrum specifically requires that testing be done throughout the sprint, as tasks are finished and for all members of a development team to self-organize in such a way that (theoretically) anyone and everyone is able to work on testing. This is likely quite unnatural for most (new) teams, but with strong leadership from the scrum master/team leader, enforcing Scrum principles, and a clear “definition of done” for all stories, this is more feasible.
Of course, this is no simple task. This discussion in a a scrum.org forum illustrates the inherent difficulty. A team must be self-organized, committed to scrum, led by mature team leaders, and have full backing from upper management in order to maintain proper balance and roles.
Spikes
Some stories represent features or technical requirements that represent a significant amount of “risk.” The risk may be technical or practical.
Two Types
Technical Risk
A story may consist of too many technical unknowns for the development team to estimate its complexity accurately. If the story requires a code or 3rd party software unlike anything the team has experience with, they will need time to investigate how difficult it will be to learn, implement, or integrate.
Functional Risk
A feature may include functionalities for the user that can’t be assessed for practicality until they are more tangible. If, for example, the product is taking an innovative approach to a problem that may be new and unfamiliar to the general user, it could be confusing or simply unpopular. Before building out all features and underlying code, it can be a good idea to create mockups, or wireframes for a test group to try out and give feedback on.
Everyone on the team will have more confidence in either
- how complex these problematic stories actually are (and therefore, how to assign them to a sprint) , or
- how likely the effort they represent will result in something of value.
Format
Spikes are unique. They represent a kind of exception to the regular workflow in Scrum. One might say that they serve as a way to keep things “scrummable,” i.e., conceptually clear and estimable.
These irregular and exceptional items have the syntax of a task but the functionality of a story.
Syntax
As with tasks, spikes are written for the development team. They are therefore
- Not written in non-technical language
- Not written from the point of view of the end user
They are in the form of a to-do list item, clearly indicating in technical terms what needs to be accomplished and by whom.
Functionality
While they don’t look like a story, they are treated like one. Spikes represent time and space in a sprint. They need to be estimated, or at least time-boxed, so that the containing sprint can be estimated fully and accurately. Unlike tasks, they do appear in the product backlog, as if they were a story.
Like stories, spikes need to be assessed and marked as “done” (or not) by the product owner.
Important note: spikes are treated much like a story, but their outcomes differ in a significant way–they result in information/guidance rather than functional, deliverable code.
Length
Since they function as stories, spikes can be no longer than one sprint. While they represent a diversion from regular sprint activity, they can and should be tackled in a similar manner as a story: as simply as possible and with clear outcomes.
Timing
Spikes are undertaken to mitigate the risk of tackling certain questionable stories. In most cases, a spike should should be planned and assigned one or more sprints prior to the problematic story.
References:
Spikes in Scrum: the Exception, not the Rule