User Stories and the Product Backlog
Driving the iterations
When organizing a project as a series of iterations, how do we decide what work to do in the next iteration?
To do this, we need to prioritize the project work that we currently know about.
Then the answer to:
“What to do next?”
will be:
“Do as much of the highest priority work that you can complete in the next iteration”.
Sprint Backlog
COMP3297: Software Engineering 2
Our iterative cycle will be:
Sprint Backlog
That means we need to maintain a prioritized list of everything that is known to be needed in the product. In agile development, that list is called the:
Product Backlog
Identify and prioritize work items
Select next incremental step to complete the highest priority items
Develop executable that delivers those completed items
COMP3297: Software Engineering
3
Higher importance.
Product Backlog
Dynamic, ordered list of Product Backlog Items (PBIs) that describe all work needed to create future releasable increments of the product. PBIs describe any work that will add value –directly or indirectly – for the customer:
all required functionalities and features,
architectural work and work to satisfy non-functionalFeature M requirements,
Fine level of detail. Ready for next iteration
fixes,
maintenance work (e.g. technical debt, requested enhancements),
Refactor A Feature Q
knowledge acquisition work (often added directly to the Sprint Backlog and not Product Backlog)
…
It makes all necessary work transparent to all stakeholders as required for empirical process control.
PBIs are removed from the top of the Product Backlog to populate the next iteration where they are decomposed inCtOoMtPa3s29k7s: StoftbwaerecEonmginpeelreintged by individual developers.
Lower importance. Coarse level of detail.
Fine detail not needed yet. 4
Agile Requirements
All projects need to document requirements to guide development and testing.
The agile approach:
Create the minimum amount of documentation sufficient to serve as an
Feature Q
The “minimum” amount of necessary detail will vary from requirement to requirement. Often only the highest risk and highest value requirements are specified in detail.
Those details can be provided in various ways. Common to express them in the form of comprehensive acceptance tests. Additional details (details of calculations, etc.) can be attached to the requirement or referenced from it.
accurate guide.
The closer we work with end users and other stakeholders throughout
development, the less detail is required.
COMP3297: Software Engineering 5
Feature M Refactor A
Role of Product Backlog
All requirements are added to the Product Backlog where they are prioritized/re-prioritized and refined over the course of the project until they are implemented and delivered.
As stated in the Scrum Guide:
Backlog refinement
For agile projects, the Product Backlog is the: Feature Q
“ordered list of what is needed to improve the product. It is the single source of work undertaken by the Scrum Team”.
That includes all features to be implemented.
COMP3297: Software Engineering
6
Feature M Refactor A
COMP3297: Software Engineering 7
Voice of the user
Trend for many years has been away from the traditional form of specification to a more user-centric form – describing requirements from the point of view of the user.
User Requirements
WHAT the user must be able to do with the system to satisfy business requirements
User Requirements “Document”
Already saw that User Requirements in a Product Backlog are the basis of a replacement for the traditional SRS
From 04 Requirements: The following are used instead:
Vision and Scope Document (or Design Doc). A dynamic Product Backlog capturing:
Ø User requirements as User Stories/Use Cases, with UI outlines and Acceptance criteria added as concrete detail
Ø Items of work needed to satisfy non-functional requirements Evaluations of product increments (working software)
COMP3297: Software Engineering
8
Google’s #1 truth
COMP3297: Software Engineering 9
Product Backlog Items (PBIs) from the user’s point of view: User Stories.
In Agile development usual to describe product features/functionality in the form of User Stories (but not a rule).
They are very short statements of intent that describe something the system needs to do for the user.
“See my total local mobile data usage”
So, the simple form of Agile delivery of value: – define a user value story,
– implement and test it in an iteration,
– demonstrate/deliver it to the user. Repeat…
COMP3297: Software Engineering 10
User Stories answer the important questions Who? What? Why? at a fine scale.
Describe functionality of value to a user and written from that user’s point of view. Understandable by a wide range of stakeholders.
A common template:
As a [role],
I want [goal],
so that [objective of value]
Who is it for – who receives the value?
What’s their intent? Why? What’s the benefit?
“As a mobile plan subscriber I want to see my total local data usage so that I can plan to stay under my capped data entitlement”
A “short simple description of a “feature” told from the perspective of the person who desires the new capability, usually a user”
It doesn’t provide details – we’ll see, those come out of conversations
with the user/customer when they are needed.
COMP3297: Software Engineering 11
Why the Why?
Developers new to User Stories have trouble understanding the purpose of the “so that” section – it seems unnecessary.
Some experienced developers omit the section if it seems obvious.
Some reasons for writing it:
o Knowing the user’s actual goal helps us improve the story as we learn more about users’ needs.
o Helps developers come up with alternative solutions.
o Helps with prioritization.
o Helps us keep useless features out of the backlog.
o Maybe stakeholders have different ideas about the “obvious”.
COMP3297: Software Engineering 12
User Stories – Level of Detail
If we wrote every user story at the highest level of detail from the start, the Product Backlog would be enormous
We saw, in practice, we only write in detail as the PBI approaches the top of the backlog.
Others are left at low level detail and can describe much larger pieces of work. These are known as “Epics”.
An “epic” is just a story that is too big to be completed in a sprint.
During backlog refinement, epics are broken down into “sprintable stories” – the effort needed to implement a sprintable story is of the order of days and so it can fit into an iteration.
COMP3297: Software Engineering 13
Examples: An epic
From that earlier COMP3297 project for the ordering and drone- delivery of medical supplies to clinics, a full story like Order Supplies, completely developed, is an epic.
It can still be described in the standard story format:
As a clinic manager, I want to order supplies for JIT drone delivery so that I don’t have to maintain a large inventory at my clinic
(The detail concerning JIT drone delivery could be omitted if it well understood that it is the core feature of the system.)
COMP3297: Software Engineering 14
Examples: Breaking down an epic
Epic: As a clinic manager, I want to order supplies for JIT drone delivery so that I don’t have to maintain a large inventory at my clinic
We would break it down into smaller sprintable stories:
As a clinic manager I want to view a list of supplies available for drone delivery
so that I can order items I need.
As a clinic manager I want to view an order so that I can check and make adjustments before placing it.
As a clinic manager I want to place my order so that I can have supplies delivered to restock inventory.
COMP3297: Software Engineering 15
Examples: implied needs
Notice that those stories may indicate other needs. If small enough, they can be considered part of the story, or they may be broken out
into separate stories:
As a clinic manager I want to view a list of supplies available for drone delivery so that I can order items.
Implies that items can be selected and added to the current order.
As a clinic manager I want to view an order so that I can check make adjustments before placing it.
Implies that items can be removed, quantity changed, etc.
COMP3297: Software Engineering 16
Examples: Themes
Another common approach: break an epic into themes, where each theme is a step in the epic’s workflow. Then write stories that contribute to those themes.
For example, in Release 2 of the ordering/drone-delivery product, which had a much larger catalogue of supplies:
Theme: Search for supplies
Story: Search by name
Story: Search by manufacturer Story: Search by category Story: …
Theme: Manage Order
Story: Add item to order
Story: Remove item from order Story: Change item quantity Story: …
Theme: …
Story: … Story: … Story: … Story: …
This technique, with slightly different terminology, is known as Story Mapping to decompose a high level goal into sequences of stories
COMP3297: Software Engineering
17
User stories as requirements: Where are the details?
Clearly, user stories when they are first recorded don’t contain sufficient detail for building the system.
That is not their purpose.
Agile development relies more on face-to-face discussion, rather than written documentation.
Best to think of a user story as a placeholder or reminder for conversations that need to take place among stakeholders, product owner, and development team at several points in development to ensure we are building the right product.
That does not mean there is nothing written apart from the short story description – we saw often a user story will point to additional information such as workflow diagrams for the story, specifications of computations involved in the story, etc.
They also should record acceptance criteria – an important part of what it means to be done.
COMP3297: Software Engineering 18
Card, Conversation, Confirmation
Before there were tools like Jira, GitScrum, Targetprocess, etc., …
…user stories were recorded on index cards or big Post-it notes and stuck to the project taskboard.
COMP3297: Software Engineering 19
Card, Conversation, Confirmation
The 3 Cs are a reminder of the essentials in each user story from the days of the index cards.
Card: A title and the “As a …” description of the story. Was written on the front of the card. It is a summary and also a promise for conversation.
Conversation: Conversations – discussions – are needed at many points: when the story is written, when it is refined into sprintable stories, when it is estimated, when it is broken into tasks during sprint planning. They determine the details.
Confirmation: Conditions of satisfaction that will confirm whether the delivered story does what is needed. They help the Development Team understand what to build, and can be used to check that the story has been implemented correctly. These were written on the back of the card.
They are the basis for acceptance tests for the story.
COMP3297: Software Engineering 20
Story with Confirmation (partial)
The Card
Browse Supplies: As a clinic manager I want to view a list of supplies available for drone delivery so that I can order items.
The Confirmation
view by category
see items page by page
see details and a thumbnail image for each item specify quantity, and add to order
order recorded
…
COMP3297: Software Engineering 21
The Card
Place Order: As a clinic manager I want to place my order so that I can have supplies delivered to restock inventory.
The Confirmation:
request from any ordering page if there are items in the order (may expand) show confirmation request including total weight
add manager’s clinic as delivery location
record date and time of order placement
show confirmation message and order number after order placed …
Story with Confirmation (partial)
COMP3297: Software Engineering 22