What do you include in a product backlog? Information that is important to capture includes a summary of the user groups who will be on the software, the deployable platforms that the requirements need to function on (for example mobile or web), and a list of the epics and user stories.
Traditionally, the requirements are split into functional and non-functional. Functional requirements are things the software will do, like an admin can update some data. And non-functional requirements are how the software should perform, like the application should respond within 1 second. A more modern approach to requirements is to use a product backlog and user stories to describe what is needed. How the user story is written is important and is covered in this article.
The outcome of creating a product backlog is to have a comprehensive list of things the software should do.
What is a user story?
A user story is a structured way of describing a requirements that helps people write good user stories. For example, A user story may look something like:
As a [type of user] like [persona] at [environment]. I want to [do something] using [device] so that [reason for task]. This will [user goal].
As you can see, the information here is displayed in a way that creates an opportunity for the people involved in a project to start thinking about the specifics required to achieve the desired goals.
What is an epic? An epic is a high-level theme or feature that is used to categorise related stories. In other words, it is a description of a coarse-grained requirement in story form. Epics should follow INVEST. This means try not to make them too general, and break large features down further.
An epic may look something like: As a [type of user] I want to [do some action] so that [reason for action]
How do you define a user story? While epics are large groupings of functionality, user stories are the small individual tasks a user performs on the product. They are a breakdown of the epic. Each user story belongs to exactly one epic and describes part of the epic in more detail. A user story is a unit of delivery for iterations, so by definition it must be sufficiently small to deliver in a single iteration.
Actually, in software engineering this format for writing user stories and epics can be referred to as a Domain Specific Language (DSL). Structuring them in a way that refers to specific parts of the software allows you to link the user stories to your software tests. This is important for ensuring the software is meeting the desired goals.
How do you write a good user story?
Consider the size of the work
How big should a story be? A user story is what you will later use when you estimate the length of your project, so it’s important to consider how the size of the story may impact your estimations later on. A user story should be small enough to improve the realism of the estimation and therefore accuracy, but not too small as to point out small and simple components that will falsely increase the time estimates. In his research paper ‘Time Predictions Understanding and Avoiding Unrealism in Project Planning and Everyday Life’, Magnes Jorgensen identifies experiments that indicate a tendency for higher estimations when tasks are broken down into smaller tasks. The cumulative estimations of a task ‘decomposed’ resulted in a higher time prediction, compared to a task estimated as a whole. In one experiment, the decomposed predictions were, on average, 9 and 10% too high, whereas the predictions of the tasks as a whole were only 2 and 5% too high. However, in another study the decomposed predictions were, on average, 0 and 8% too low, whereas the predictions of the tasks as a whole were, on average, 13 and 26% too low. Though this shows it’s not clear whether decomposition will result in less or more accurate estimations, it is important to note that the size of the user story or requirement has a clear impact on the estimations.
Consider the description length
Something else you may not have considered when writing a user story is to be careful of the description length. Jorgensen in his research paper ‘Time Predictions Understanding and Avoiding Unrealism in Project Planning and Everyday Life’ writes of the unconscious bias around the length of the story’s written description. He mentions an experiment where a task was described to two groups in two different ways. The group that received the shorter version of the task description was inclined to estimate a shorter time period to complete the task, and the group that received the longer version predicted it would take longer to complete. However, Jorgensen notes that while the impact of this bias when it occurs is significant, it is less likely to be present where estimations are made by people experienced in the task.
Summary
Remember, before the project can proceed to development the backlog needs to be finalised and all information added. The more stories you can log the better, as it helps maintain accountability for the project moving ahead. Just keep in mind some of the considerations I have mentioned and you will be fine.
When it later comes to the time to estimate the project, you will refer back to this backlog to record an estimate and risk score against each story.
Written by Shannon England
Branding, Communications and Marketing
Shannon is our branding and marketing go-to. When she isn’t working on our communications and marketing campaigns, she is typically drinking coffee or at the local plant shop.
