{"id":2886,"date":"2016-07-11T10:13:04","date_gmt":"2016-07-11T08:13:04","guid":{"rendered":"http:\/\/leapfrog.nl\/blog\/?p=2886"},"modified":"2016-07-11T10:14:30","modified_gmt":"2016-07-11T08:14:30","slug":"doing-ux-inside-of-scrum","status":"publish","type":"post","link":"https:\/\/leapfrog.nl\/blog\/archives\/2016\/07\/11\/doing-ux-inside-of-scrum\/","title":{"rendered":"Doing UX inside of Scrum"},"content":{"rendered":"

Some notes on how I am currently \u201cdoing user experience\u201d inside of Scrum. This approach has evolved from my projects at Hubbub<\/a> as well as more recently my work with ARTO<\/a> and on a project at Edenspiekermann<\/a>. So I have found it works with both startups and agency style projects.<\/p>\n

The starting point is to understand that Scrum is intended to be a container. It is a process framework<\/strong>. It should be able to hold any other activity you think you need as a team. So if we feel we need to add UX somehow, we should try to make it part of Scrum and not something that is tacked onto Scrum. Why not tack something on? Because it signals design is somehow distinct from development. And the whole point of doing agile is to have cross-functional teams. If you set up a separate process for design you are highly likely not to benefit from the full collective intelligence of the combined design and development team. So no, design needs to be inside of the Scrum container.<\/p>\n

Staggered sprints are not the answer either because you are still splitting the team into design and development, hampering cross-collaboration and transparency. You\u2019re basically inviting Taylorism back into your process\u2014the very thing you were trying to getting away from.<\/p>\n

When you are uncomfortable with putting designers and developers all in the same team and the same process the answer is not to make your process more elaborate, parcel things up, and decrease \u201cmessy\u201d interactions. The answer is increasing conversation, not eliminating it.<\/p>\n

It turns out things aren\u2019t remotely as complicated as they appear to be. The key is understanding Scrum\u2019s events. The big event holding all other events is the sprint. The sprint outputs a releasable increment of \u201cdone” product. The development team does everything required to achieve the sprint goal collaboratively determined during sprint planning. Naturally this includes any design needed for the product<\/strong>. I think of this as the \u2018production\u2019 type of design. It typically consists mostly of UI design. There may already be some preliminary UI design available at the start of the sprint but it does not have to be finished. <\/p>\n

What about the kind of design that is required for figuring out what to build in the first place? It might not be obvious at first, but Scrum actually has an ongoing process which readily accommodates it: backlog refinement. These are all activities required to get a product backlog item in shape for sprint planning. This is emphatically not a solo show for the product manager to conduct. It is something the whole team collaborates on. Developers and designers. In my experience designers are great at facilitating backlog refinement sessions. At the whiteboard, figuring stuff out with the whole team \u2018Lean UX\u2019 style. <\/p>\n

I will admit product backlog refinement is Scrum\u2019s weak point. Where it offers a lot of structure for the sprints, it offers hardly any for the backlog refinement (or grooming as some call it). But that\u2019s okay, we can evolve our own.<\/p>\n

I like to use Kanban to manage the process of backlog refinement. Items come into the pipeline as something we want to elaborate because we have decided we want to build it (in some form or other, can be just an experiment) in the next sprint or two. It then goes through various stages of elaboration. At the very least capturing requirements in the form of user stories or job stories, doing sketches, a lo-fi prototype, mockups and a hi-fi prototype and finally breaking the item down into work to be done and attaching an estimate to it. At this point it is ready to be part of a sprint. Crucially, during this lifecycle of an item as it is being refined, we can and should do user research if we feel we need more data, or user testing if we feel it is too risky to commit to a feature outright. <\/p>\n

For this kind of figuring stuff out, this \u2018planning\u2019 type of design, it makes no sense to have it be part of a sprint-like structure because the work required to get it to a \u2018ready\u2019 state is much more unpredictable. The point of having a looser grooming flow is that it exists to eliminate uncertainty for when we commit to an item in a sprint.<\/p>\n

So between the sprint and backlog refinement, Scrum readily accommodates design. \u2018Production\u2019 type design happens inside of the sprint and designers are considered part of the development team. \u2018Planning\u2019 type of design happens as part of backlog refinement.<\/p>\n

So no need to tack on a separate process. It keeps the process simple and understandable, thus increasing transparency for the whole team. It prevents design from becoming a black box to others. And when we make design part of the container process framework that is Scrum, we reap the rewards of the team\u2019s collective intelligence and we increase our agility.<\/p>","protected":false},"excerpt":{"rendered":"

Some notes on how I am currently \u201cdoing user experience\u201d inside of Scrum. This approach has evolved from my projects at Hubbub as well as more recently my work with ARTO and on a project at Edenspiekermann. So I have found it works with both startups and agency style projects. The starting point is to … Continue reading Doing UX inside of Scrum<\/span><\/a><\/p>","protected":false},"author":2,"featured_media":0,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"_jetpack_newsletter_access":"","_jetpack_dont_email_post_to_subs":false,"_jetpack_newsletter_tier_id":0,"_jetpack_memberships_contains_paywalled_content":false,"_jetpack_feature_clip_id":0,"_jetpack_memberships_contains_paid_content":false,"footnotes":"","jetpack_post_was_ever_published":false},"categories":[625],"tags":[1124,1120,19,1121,1125,230,1122,1123,1119,54,53],"class_list":["post-2886","post","type-post","status-publish","format-standard","hentry","category-articles","tag-agile","tag-collaboration","tag-design","tag-development","tag-kanban","tag-process","tag-project-management","tag-scrum","tag-teams","tag-user-experience","tag-ux"],"jetpack_sharing_enabled":true,"jetpack_featured_media_url":"","_links":{"self":[{"href":"https:\/\/leapfrog.nl\/blog\/wp-json\/wp\/v2\/posts\/2886","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/leapfrog.nl\/blog\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/leapfrog.nl\/blog\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/leapfrog.nl\/blog\/wp-json\/wp\/v2\/users\/2"}],"replies":[{"embeddable":true,"href":"https:\/\/leapfrog.nl\/blog\/wp-json\/wp\/v2\/comments?post=2886"}],"version-history":[{"count":0,"href":"https:\/\/leapfrog.nl\/blog\/wp-json\/wp\/v2\/posts\/2886\/revisions"}],"wp:attachment":[{"href":"https:\/\/leapfrog.nl\/blog\/wp-json\/wp\/v2\/media?parent=2886"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/leapfrog.nl\/blog\/wp-json\/wp\/v2\/categories?post=2886"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/leapfrog.nl\/blog\/wp-json\/wp\/v2\/tags?post=2886"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}