UX in the balanced team

In most development methods, there is a business side and a developer side. Particularly, in Scrum, there is a Product Owner and a Team (the latter including the Scrum Master). Developers find it quite easy to categorize people into these two blocks. If you do system architecture or software testing, you are preferably with the Team. If you do requirements engineering or pilot studies, you should definately inform the Product Owner. The Team is usually kept quite small, under 10 members, to simplify communication between Team members. The Product Owner is one person, the one with all the business knowledge, to ensure that there is one and only one way for business demands to leak into the Team. Hence, when a UX person shows up on the scene, he or she is automatically placed with the Product Owner. All well in theory, but in practice it is another matter.

In recent articles I’ve written about creating an business impact map together with the Product Owner as well as working tight with the team during the sprint with design sessions and continuous usability testing. So my answer is obviously that the UX person(s) should join both the Product Owner and the Team.

Working with the Team, actually in the Team, creates a greater understanding of the user experience and often engages the developers to think more in usability terms. I’d say that is a good thing. One way to achieve the connection the UX person would like to have with the developers is to really incorporate the UX work into the sprints, by writing UX stories, putting them on the task board and estimating points for them. The UX person should really take an active (and somewhat equal) part in the sprint.

Apart from this, as stated above, it is obvious that the UX person should be involved with the Product Owner as well. A great way of involving the competencies necessary is to create a cross-functional Product Owner Team consisting of people with:

• Domain knowledge (the original Product Owner)
• Developing and architectural skills
• Design skills (especially UX)
• A vision of the product’s future (and perhaps the whole product range)

This skill set will probably not fit in one person’s head, thus requiring a Product Owner Team. Jeff Patton argues that there should at least be people covering the following three areas comprising the team:

Patton explains that to get benefit from the software, it must be used (usable/desirable), cost effective (feasible) and give value back to the business (valuable). This means you need to incorporate business concerns in design decisions. So let’s add one more bullet, one more role on the list of people in the Product Owner team that shall have:

• Business perspective (perhaps in the form of a Business Analyst)

This is often mentioned in the role of information architect, and it might fit there. In my opinion, the business perspective requires greater focus and a better overall view. A role in traditional project containing this perspective might be the one of the product manager.

For large applications and product ranges there might be several Product Owner Teams, lead by a Super Product Owner or such a Product Manager mentioned above. This hierarchy is quite common for the developer teams, calling the supergroup a Scrum of Scrums.

In this picture three teams are supported by one Scrum Master each, and the Scrum Masters have a Scrum of Scrums team together with the Project Lead. Equivalently, there can be a Scrum of Scrums team with the Product Manager and a Product Owner Team for each developer Team.

So, let’s focus on the UX person’s responsibilities in a Product Owner Team. They are:

• Creating measurable product goals, i.e. effects. When I discussed Business impact mapping I used the example of a hotel that wanted to attract more customers. A measurable goal for that could be to get 50% more customers in a month.
• User research leading to personas. This is work done that will contribute in a great way to the whole product line. An investment for the future, and as being such, it might be that user research should be done continuously outside the project. The first set of Personas, though, should be simplistic to help you learn what you know now and what you need to fill in later, to get the project going.
• Creating measurable usability goals, to attend to and measure the user’s perception of the system’s usefulness. A usability goal from the hotel example was that the customers/users should feel safe when staying at the hotel. A measurable, although perhaps unachievable goal could be that 100% of the customers should say that they feel safe.
• Creating the actual effect backlog. The UX person should write full epics with user needs and context in them. This is to make it easier to tie the whole project together after it has been divided into smaller chunks/stories and implemented.

These epics usually consist of a sentence describing the problem in short, on the form of As a [stakeholder], I want [feature] so that [benefit].  The UX person’s job is to get more substance into the [stakeholder] and the [benefit] parts. The persona constitutes the former part and the usability goal the latter. Apart from this, every epic should have some kind of basic interface sketch connected to it, since communicating with pictures AND words gives the best understanding. This is to avoid writing a detailed design document. Also, specifying acceptance criteria, what is the definition of Done for every epic, should also be the UX person’s responsibility. Most of these epics could have an acceptance criteria corresponding to the measurable usability goals and/or the effect.

The epics can also be used for creating high-level scenarios (for design sketching or usability testing). The easiest way of doing this would be to combine stories (the [feature]-part for a certain user/stakeholder) into sentences, using conjunctions to connect them. An example:

As a hotel guest, I want to feel safe during my stay, so I use my personal keycard to get into my room and use the extra latch to lock the door as well as the ordinary lock.

For lower-level scenarios, to be used as functional requirements or similar, use stories instead of epics.

Other tasks for the UX person involves evaluating spikes with users to investigate the implications of new technologies and of course prioritizing the backlog, which is a constant task.

When the system is released and goes into operations phase, the job for the UX person is not finished. To ensure that the general usability of the system isn’t degraded over time, there is a need to continuously measure the effect and usefulness, especially in an environment where other people are responsible for adding and removing content (e.g. a website with a news page).

That concludes this article and like all the methods and techniques I write about, it is all contextual. This might or might not work for you. Please tell me in a comment below how you incorporate UX in an agile project.