Working ahead of the Sprint, or in the Sprint? That is the question. A big question for Experience professionals.
Designing ahead of the Sprint allows more time for research and iteration giving UX a better grasp of a unique problem. But sometimes understanding the problem outside the context of what the rest of the team is working on may not always be best. It comes down to “context”.
How does UX stay in sync with the Scrum team, and take advantage team knowledge, and do design research to find the best best possible solution? It means working more Inside the Sprint with the scrum team. But then again who doesn’t like designing the “perfect solution” on our own with no limitations?
I always worry about dropping a “well thought” feature on the dev team without them having an opportunity to provide input. Doing that without input can cheat the process, and shortcut what should be a richer working relationship. But how best to do that effectively while serving the end product and the user?
For this very reason, I try to work within the current sprint while simultaneously researching (and wire framing) features for future sprints. This means juggling more sooner for a better result. Staying present in the current sprint keeps the intent on the rails while increasing understanding. Redressing past features is one of the biggest impacts to cost and schedules.
I found a great article on this subject. Hope you enjoy!