How defining the right product backlog can influence user-centered design
To deliver value to a customer you first need to understand what that customer needs. In other words, you must define the problem before designing the solution.
Steve Jobs once said, “if you define the problem correctly, you almost have the solution.” This statement coincides with the ideas behind User-Centered Design (UCD).
“If you define the problem correctly, you almost have the solution.”
The Interaction Design Foundation defines UCD as “an iterative design process in which designers focus on the users and their needs in each phase of the design process.” Why iterative? To ensure that the user is always kept top-of-mind, there needs to be a constant feedback loop with the product/service developers and the target users so that the people creating the product/service can make adjustments according to the users’ needs.
Agile, Scrum, and UCD
Though not stated explicitly, Agile and Scrum both support the basis of UCD. For instance, the first of the 12 Agile principles states, “our highest priority is to satisfy the customer through early and continuous delivery of valuable software.” Similarly, the Scrum Guide states, “Scrum Teams deliver products iteratively and incrementally, maximizing opportunities for feedback. Incremental deliveries of ‘Done’ product ensure a potentially useful version of working product is always available.”
Take a look at the similarities of the following graphics for further evidence of the relationship of Agile, Scrum, and UCD.
Figure 1: Visual representation of Scrum (Image source: Visual Paradigm)
Figure 2: Visual representation of the UCD process (Image source: Product Tribe)
Notice how both diagrams feature a looping of different steps or phases. The idea of product development happening in “loops” is not unique to Scrum or UCD, it’s simply the resulting structure of an iterative development life cycle.
The Importance of Remembering
While delivering to the customer frequently and getting consistent feedback is great, an iterative process is only valuable if the people doing the work act on the feedback they receive. Not acting on user feedback can potentially cause a need for rework, extended project timelines, or unhappy customers.
One of the reasons why a development team may not act on the feedback provided by users is that the team may have forgotten what that feedback was. While face-to-face conversations are important to Agile, Scrum, and UCD, there still needs to be a method for remembering the information and decisions discussed during those conversations. Hence, some form of documentation will always be necessary when working on a project.
The Scrum Guide suggests documenting important information in a Product Backlog: a list of prioritized work items including all features, functions, requirements, enhancements, and fixes for a product.
These work items, referred to in the Scrum Guide as Product Backlog Items (PBIs), are meant to represent valuable increments of potentially shippable work. PBIs may be written as user stories, tasks, use cases, or something else; regardless of the label, a PBI should have the following attributes: (1) description, (2) order, (3) estimate, and (4) value.
In the context of UCD, these attributes can be translated to mean the following:
- The problem the user is facing (Description)
- The importance/urgency of providing a solution (Order)
- The assumed effort it will require to develop a solution (Estimate)
- The intended benefit the user receives as a result of the solution (Value)
Asking The Right Questions
Robert Half once said, “asking the right questions takes as much skill as giving the right answers.” This statement strongly applies to the process of defining work for a user-centered design.
A developer, product designer, product owner, or anyone helping defining a PBI, is not only responsible for providing the answers that will help develop a solution, but also for asking the right questions that will help determine what solution is needed.
“Asking the right questions takes as much skill as giving the right answers.”
After receiving and documenting feedback from your users, it’s important to ask a number of clarifying questions to ensure that you understand the problem and the work required.
The following list includes a variety of questions you may want to consider when defining a PBI to ensure that the PBI is well defined, valuable, and ready for someone to start working on it.
Questions
What’s the value of this PBI?
- Who are the users that the implementation of this PBI impacts?
- What is the resulting business value of implementing this PBI?
- Is completing this PBI necessary to complete the associated Epic?
- What’s the potential consequence of not implementing this PBI?
What’s required for this PBI to be accepted as Done?
- What tests must pass for this PBI to be accepted?
- In what environment does this PBI need to be tested?
- How is the PBI approved for acceptance?
- Does this PBI require manual or automated testing?
- What’s the desired outcome of this PBI?
Aside from completing the work, what’s expected of team in regard to this PBI?
- Does the outcome of the completed PBI need to be presented during Sprint Review?
- Does this PBI require a release?
- Does this PBI have a strict deadline?
- Who determines which bugs found while working on the PBI need to be fixed immediately and which can be placed in the backlog?
- Will working on this PBI disrupt the work of anyone outside the team?
- Are there any risks that must be managed that are associated to this PBI?
- Does working on this PBI require any special communications outside the team?
Can the team independently complete this PBI?
- Is this PBI dependent on another PBI?
- Can this PBI currently be completed using only resources from within the team?
- What outside resources, if any, are required to complete this PBI?
- Is there anything blocking the team from completing this PBI?
- Does completing this PBI require any special permissions?
- Does completing this PBI require any software or tool installations?
- Can this PBI realistically be completed in a single sprint?
What questions do you find most helpful when defining a PBI? Write your responses in the comments!
