Every successful Scrum project starts with a solid backlog of items. Developing a good backlog requires discipline and vision.
Building a Backlog
Building a good backlog is not difficult, but does take practice. We treat backlog development as a process of refinement. The important thing is to just get started. It will be a stream-of-consciousness at first. That's ok. Successive passes through the backlog will yield ever-clearer guidance about desired features. Eventually we will have clear direction for each feature.
Creating Stories
When kicking off a project we add lots of stories to the backlog. In our experience this works best when story-writers don't worry too much about specifics.
Why quickly? Our goal is to write down ideas first and think about organization and clarity later. Editing stories interrupts the idea flow. It brings focus to individual items rather than the whole application.
Refining
Once we have a good picture of desired features it's time to refine the stories.
Story refinement includes examining relationships between stories. After finding a number of related stories we often group them together. This allows tracking, and sometimes development, of the group as a whole. Refining also applies to story scope. Some stories look simple but a quality review reveals unstated assumptions or other complications. In this case we break up the complicated story into a number of new simpler stories.
Epics
Realizing a story is more complicated than expected usually indicates the discovery of an Epic. An Epic defines a large feature or system and is comprised of many individual stories. Epics usually require significant development resources.
In an example of Epic discovery, a feature story might state:
As a reader, I want to post comments to an article.
On the surface, it seems like a pretty finite story, but as we dig into it we find it's really an Epic that we'll name something like Commenting that will consist of the following stories:
As a reader, I want to be able to use Markdown to author article comments.
As a reader, I want my name to be persisted between posts so I don't have to re-enter it.
As a reader, I want to be able to reply to a specific comment.
As a reader, I want to be able to @-mention other commenters in the thread in my post.
As a reader, I want to easily be able to embed YouTube videos in my comments.
Some of these stories might be very important now and others could be deferred to a later release. Most of your earlier stories will likely become Epics as you begin refining them.
Storytelling
Writing stories is the art of describing features the Customer asked for or the Product Owner wants.
We use a standard template for stories:
As a
<ROLE>, I want|need|expect that<SOME FEATURE>[so that<REASON>]
For example, application users want to enter their email address and receive an email prompting them to reset their password.
Instead of issue titles like:
Password reset
or
Send email with link allowing user to reset password after submitting email
We write the story:
As a user, I want to reset my password so I don't have to ask tech support to do it for me.
or even:
As a user, I want to reset my password.
Focusing on this format forces us to literally put the user first. We think in terms of the user's experience and interactions with our software rather than implementation details.
Additional Backlog Items
Not every development item is a feature request. Development team needs which are not user requests include Tasks, Spikes, and Bugs.
Tasks
Tasks are quantifiable work items which are typically not visible to our client. For example, an epic which calls for sending emails to all users might include the following task:
Hook up MailChimp for outbound emails
Unlike Stories, Task implementation details can be part of the title.
Spikes
A spike is time spent researching an idea or proving a concept. Examples:
Determine which email provider we should use.
or
Figure out best practices for password security rules.
Bugs
Bugs include code that produces incorrect results or an interface that does not work as intended. When starting a project it's unlikely your project has bugs as you haven't yet written any software. However once coding begins there will be bugs to track down and fix.
A good method for recording bugs is to focus on expectations. Rather than trying to diagnose and/or suggest the solution in the title of the Bug issue, simply state the expected behavior that isn't working. For example:
When submitting an email to password reset form an exception is raised.
This is clearly not expected behavior.
Here is another, more subtle bug:
After submitting my new password to reset my password, nothing happens.
In the second bug report we can infer that nothing happening is not the expected behavior. The missing behavior might be obvious to the development team who knows the user is supposed to be redirected to a login form. However, it's important to get more details from the user in the bug report because different interpretations between end users and developers have been known to exist. So the body of the bug report might look like:
I expected that after entering my new password I would be logged in and taken to my dashboard. Instead, I am redirected to the login form.
The bug report body text shows that this is a misalignment of expectations. There are several ways of handling it:
- Roll with it being called a bug, track it as such, and do the work necessary to align the software with user expectations.
- Push back on the user and explain why it's supposed to work the way it does. Offer to add text guidance on the password reset form explaining what will happen next.
- Convert the Bug issue type to a Story: As a user, I want to be logged in immediately after resetting my password.
Conclusion
The most important aspect to backlog generation is getting started. Don't wait for things to be perfect or well-formed. Get ideas out of your head and into the backlog to reduce your cognitive load, help spur ideas and discussion from your team, and get the ball rolling. Write backlog feature stories as user-centered initiatives. Subsequent backlog review iterations will help refine the big picture, and allow splitting too-complex stories into an Epic collection of simpler issues.