The company I joined late last year has decided to move to Scrum, and much of the responsibility for setting up processes, tools and designing products has come under my role as the new guy with spare time and as a user experience designer to introduce a different way of approaching design.
I have had some limited exposure to Scrum in my previous role at Telogis in New Zealand but not as an integrated team member; more a designer on the fringe who was consulted to provide advice as required but largely operated outside of the teams’ sprints.
As a product owner (and yes I’ve now picked up the habit of starting every sentence with As a … I want to …) and UX designer I’m finding it incredibly difficult to get it right. Not in the dogmatic by-the-book sense of “right” but in implementing Scrum to realise the benefits of Scrum and not falling into the trap that so many practitioners do of simply wrapping up functionality and features as “user stories” that results in clumsily-written vague functional requirements with none of the benefits of telling plausible stories from real people’s perspectives! For example “As a user I want to OAuth because client asked for it”.
I’ve been so comfortable with my longform documentation, sets of baselined wireframes, personas, diagrams and concept maps, and weeks of deep dive thinking and ideation that Scrum frightens me. I now have to be comfortable with tasking developers with starting work – actual coding work – on an incomplete product within days of starting a new project and trusting that in precisely 7 days something actually usable, relevant and useful will be available for both myself and the client to review.
While moving clients away from a focus on implementation through user stories we’re also letting clients get even closer to the detail through frequent reviews of what has been built thus far and involving them in decisions of where we go next … conversations we’ve previously avoided because of the dreaded scope creep. Wireframes are now relegated to the role of documenting team design decisions rather than being a prescriptive output that I have control over.
I’m deeply worried that my design expertise will count for little and in fact may not be as important to delivering a successful product as I thought. As a product owner I feel less … special. Dispensable. It’s no longer about me and all about the product and the team. It’s depersonalising although probably in the best interests of the client.
But just from a technical aspect, these user stories are just so difficult to do properly … to ensure they’re pitched at the right level to not be too vague, not be prescriptive, that we focus on the most valuable stories while also being mindful of the fact we eventually have to deliver a “complete” product. It’s a paradigm shift that is really messing with me and requiring significant concentration and reflection to stay on track and ensure the full coverage that I would typically be assured of through more methodical approaches.
I’m sure I’ll find my rhythm eventually and I have no doubt I’ll be competent in this role, but one more time: Scrum is bloody hard.
Shout out though to everyone who has been giving me advice and answering my questions like Scott Sehlhorst on splitting user stories across sprints in order to incrementally enhance the solution through progressively raising the bar via layered acceptance criteria. Yeah.
Also want to thank Sandy Mamoli over in Wellington NZ from Nomad8 for her great blog posts on Agile who, being a typical Kiwi, couldn’t be persuaded to not publish my shitty illustrations I added to her article on acceptance criteria. Sigh.
As mentioned, there are a lot of Agile practitioners out there who teach others about writing user stories but even to a newbie such as myself (although perhaps better informed given my UX expertise) I can tell they just don’t get it. There are even some prolific authors out there who give out advice like using hours to estimate stories and not bothering with the third part of the user story format, the all-important user goal! It’s hard to sift through all the poor advice and articles to find the few who truly get it.
Jeff Patton’s 5-star book User Story Mapping has been wonderful not just for user story mapping but just the basics of Scrum and writing user stories. As a designer it has really helped me bridge the chasm between the old way of working and the new.
If you enjoyed this article please share it with your friends and colleagues.