Many Scrum Teams struggle to embed UX work in their user stories and sprints. A regular question regarding Scrum and UX is:
Should UX work one sprint ahead of the development team?
A common approach looks like this:
This may feel waterfall-ish because it is waterfall-ish. Maybe you try to convince your team that working like this is bad practice. But developers will complain, they can not estimate a user story, because they don’t know what exactly they should implement.
Why Is This a Bad Approach?
1. Late Delivery
The value will only be delivered at the end of the second sprint and only in the best-case scenario. The best-case scenario occurs only rarely. More often than not, it will look like this:
2. Missing Early Feedback
In the scenario above, you will only get feedback at the end of the second sprint. You could get feedback on designs after the first sprint, but this will not help you get feedback on the overall experience the user will face. Remember: You want to get feedback on something you created with value, not on working results.
3. Longer Cycle Time
Cycle Time is the time it takes to complete the production of one unit from start to finish.
Imagine the following, very common scenario: After the second sprint, you get some feedback during the sprint review, to adapt the solution you created. Then, in the third sprint, the team works on that feedback. The cycle time for this solution might be three sprints.
What’s the Value of UX and Development Working Together in the Same Sprint?
A collaborative approach, where UX and development work together on a solution in the same sprint will result in something like this:
At the end of the first sprint, you have created (maybe just a little) value for the end-user. During the sprint review of the first sprint, you gather valuable feedback on your solution, instead of working results.
If there is a need to adapt your solution after the first sprint (this is a common and desired situation), the team will work on that feedback during the second sprint. Very often after the second sprint, your team created a solution, that satisfies the product owner, stakeholder, and user. It is a win-win-win situation.
Let’s Take an Economic View
We will compare the following two scenarios:
1. Scenario: UX Is One Sprint Ahead
Facts:
- Difficulties for UX and Dev people regarding estimation of the solution
- A lot of hand-offs between UX and Dev
- Missing feedback opportunities on the solution
- Longer development cycles
2. Scenario: UX and Development Work Together in the Same Sprint
Facts:
- Estimation of the whole solution gets easier
- Fewer hand-offs as UX and Dev are working together
- Early/more feedback opportunities
- Shorter development cycles
By changing the way we work together, we can reduce the overall time for development. This helps us to achieve better economic results while creating a solution tailored to customer needs.
