Scrum is a form of Agile project management that I have been working with for over a year. Our development team was the first in the company to adopt Scrum in favor of Waterfall, so everyone was on a learning curve.
We quickly realized that in addition to the QA role, UX doesn’t have a well defined place. Many questions immediately popped up such as, “Does UX work get points toward the sprint? When does the UX work happen if developers need to be building from prototypes from day one of the sprint?
Luckily, there was a technology evaluation period in which I was able to prototype ahead of the sprint cycle. Even so, many of the user stories changed and the designs were no longer relevant by the time development work started. The development team quickly caught up to my prototypes and I was designing features for the stories in the current sprint. This is all but unavoidable when meeting the sprint goals is top priority.
Our cycles were unsustainable until we implemented code freezes before the end of every release. This way, QA could have time to review the work from the sprint in a stable state. During this time, I was also able to design ahead for the next sprint. Meanwhile, developers busy themselves on bug fixes from previous sprints that inevitably get carried forward.
As for points, I assign them as usual in sprint planning meetings and just work ahead when necessary. The work gets done sooner or later, and the points are spent. If tasks, features or stores change, re-evaluate the point estimate or add the new work as an additional task. This helps prevent scope creep and preserves the ability to stay ahead of the game.
Lessons learned:
- Stagger the Sprint about a week ahead of the UX work.
- Work with the developers to complete stories
- Everything costs points — UX work isn’t free (mock ups, revisions, prototypes and implementation)
- Set aside time for user testing each sprint.