Incorporate UX/UI issues in the Sprint Backlog?
Hi all,
I'm a UX designer in a scrumteam (I'm part of the DEV team), but we are currently reviewing the way we incorporate UX/UI issues in our backlog. The team feels that every team member should have stories in the SBL, which means my design issues should be there as well. But since my UX/UI stories aren't delivering increments (and they may take while because a lot of research and designing is happening and it will take longer then a sprint), I am not favoring the 'put all UX/UI issues in the SBL without an estimate and just leave them there when the sprint is over and the work is not done yet, so it will still be in focus when we start a next sprint.'
Currently my work is in the BL, not in de SBL. So what I do is: the PO comes to the team with an issue, we evaluate if UX/UI is needed in a refinement, and I start working on it. In the Utopia way of working, I should be 2 sprints ahead of building said story.
But my team members wants to have these kinds of issues more in focus, so that everyone knows what everyone is doing. Since we're shifting our focus during the daily away from when people have been doing to what issues are there on the SBL and who is working on it/who can help fix this issue (which I wholeheartedly agree with). But this means that the team also wants to include my UX/UI issues in the SBL.
I don't favor this, because of reasons mentioned above, but I was wondering how we should do this. I already saw a lot of people mentioning that a UX Designer shouldn't be part of a DEV team, which I disagree upon. I work closely with my team in order for me to do my UX work:
- Is what I envision technically doable?;
- I include the team in UX work as well (2 pairs of eyes see more then one);
- When they are building my designs, I work closely to make sure the increment is as I designed;
- Not to mention all the usability and UX testing of certain elements, for which I work closely with the FE developers in my team.
What is your opinion about this? Thank you in advance!
Please review this sites suggested reading for their PSU exam as it covers this very topic.
But my team members wants to have these kinds of issues more in focus, so that everyone knows what everyone is doing.
Who would then be accountable for producing at least one Done increment, each Sprint, out of those separate issues people have established great transparency over?
Everyone...or no-one because they're just doing their own bit?
What about you, given that your work is largely about refinement? Are you accountable?
It sounds like there is a great desire for transparency over work, and not enough appetite for transparency over who the Developers are, and who is therefore accountable for producing a Done increment.
I do not believe that UX designers should be considered to be a Developer, nor should their work be in either the Product Backlog or the Sprint Backlog.
To define the terms:
- Developers are the people who are committed to creating any aspect of a usable Increment each Sprint.
- The Product Backlog is an emergent, ordered list of what is needed to improve the product.
- The Sprint Backlog consists of a Sprint Goal, a set of items from the Product Backlog that were selected for the Sprint, and a plan for delivering the Increment and achieving the Sprint Goal.
- The Increment is a set of changes to a product or service that move the product closer to the Product Goal.
Although a UX designer may support Developers in their work, the vast majority of a UX designer's work consists of user research, identifying and managing user personas, information architecture, interaction design, designing user interfaces, conducting usability studies, and talking to stakeholders about how they interact with the product. In organizations with a design system, the UX designers are also heavily involved in building and maintaining the design system. All of this work much more closely aligns with creating and communicating Product Backlog Items rather than directly making changes to the product that to implement the changes described within a Product Backlog Item.
Generally speaking, UX designers are more closely aligned with product management than product development.
The output of the UX design process is new or modified Product Backlog Items that would be further refined by the whole Scrum Team.
It may be OK to use Scrum to manage the UX design work. The product of UX design would include designed and tested mockups, a design system, and Product Backlog Items. If you have a team of UX designers supporting a single product, then using a framework like Scrum could work. In this case, the UX designers would be the Developers of their own product and what they work on would be ordered by the same Product Owner as the Product Owner of the product. The cadence may or may not match the cadence of the product development team. You can bring in Developers to act as stakeholders, just like the UX designer may be brought in to support the Developers as a stakeholder or subject matter expert to help make sure the designs are feasible and achievable.
You don't need to be a part of the Developers or use their Product Backlog or Sprint Backlog to collaborate closely. Instead, be a stakeholder. Participate in Sprint Reviews. Even better would be to review the work as it is complete or even while it is in progress. There's nothing preventing Developers from consulting with subject matter experts. It can also be beneficial to teach basic UX principles to the Developers to enable them to make more detailed decision on their own and allow the UX designer to be more forward thinking and strategic rather than tactical.
I think the work needs to go into the Product Backlog and the Sprint Backlog.
1. You need to inform the team of what is being done and what the results are. This gives transparency.
2. The team should be crossfunctional, and other members should be able to help or do the work. So it needs to be documented just like any other work item.
3. What you produce may not be code, but the work you do contributes to the development of the product. The Product Backlog is one of the important parts of the documentation and should incorporate all the work done to create the product. And so your document is an increment of the product.
4. If your Product Backlog Items do not fit in the Sprint, they need to be split so they do fit.
The Suggested Reading for PSU I is indeed a good source of information. What I think is very interesting is the Dual Track article, it goes further into the "design is upfront of development" mindset and shows how to better integrate UX into Scrum.