7

I always have trouble deciding who the actor should be and therefore how user stories should be written.

For example:

As a site owner I would like to display a carousel of products on the homepage so that I can promote many products.

vs.

As a user I would like to see a carousel of products on the homepage so that I can easily see products to buy.

I always have this trouble - which is correct?

  • Neither is really correct. I think Daniel's answer does a good job of explaining how you might want to re-evaluate the purpose of your user stories to make the user stories both more valuable and more meaningful to the team. – Todd A. Jacobs Feb 23 '15 at 0:18
  • It's also worth noting that you can have more than one related user story. If you have multiple value consumers, the effort of having to integrate various related stories (each with a different focus or beneficiary) can be valuable to your process, too. – Todd A. Jacobs Feb 23 '15 at 0:20
8

Tl;Dr; The reason to include an actor in the story is to provide context on who it is benefiting. In this case, the site owner derives little, if any value from the story, so you'd go with the site viewer.

However, the reason this example is particularly confusing is that the story dictates implementation. A user story should describe the need being served rather than the way to implement it. In this example, we've already decided we want a carousel and we've completely lost the need being served. This is actually a pretty common problem with graphic design elements.

To make this a little more clear who benefits, we have to back up a bit. The carousel idea is usually used to draw attention to new offers, so a basic story would look something like this:

As a customer, I'd like to be presented with new offers in a highly visible place on the home page so that I don't miss out on new deals.

In this story, it's clear that I'm trying to serve the customer by placing important and timely information in a highly visible area. But, there is no reason to create a carousel (or anything more than a basic banner). For that we have to look at the need it's filling. In most cases, it's so you can show a number of different deals without taking up too much screen space, so we have a second story:

As a marketing coordinator, I want to be able to display up to five deals on the homepage without using too much screen space so that I can run multiple specials simultaneously.

I still don't have a carousel, but the developers and designers will work together to find the best approach, which may be a carousel.

Note: There are a lot of angles to this. Maybe a carousel has been used many times and it's more work to do it as two stories, so you combine it back into one. I broke it out this way to specifically look at the question of who the story is for. If you combined it back into one story, I would still have the customer as the actor because the primary value is to entice the customer with new deals. The ability for marketing to create those deals is only a response.

  • +1. I liked your answer because it really highlights the fact that there are a lot of problems with the way the OP is looking at the wh0le user-story concept, and that you provided a set of concrete examples of how they might re-imagine their user story process. I think you did a great job of explaining the purpose of the process, rather than focusing on just its implementation in the OP's singular (and rather limited) use case. – Todd A. Jacobs Feb 23 '15 at 0:17
1

You may want to assign roles to the various types of users that may have use cases. These could include:

  • Customer,
  • Administrator,
  • Support/help desk user,
  • Super User
  • Application

The actor(s) should be the roles that require the functionality being specified. In some cases, certain actors may have different capabilities.

0

The author oft a story should be the customer. If your paying customer is not the user, I recommend to focus in the most important stakeholder - the one with the most influence in the buy-decision regarding your product.

If you have several important stakeholder introducing different user stories (leading to different functions) you should have all of them in your backlog.

  • I think you misread the question: it's about the "actor" in the story, not the "author" of the story. – Vicki Laidler Feb 21 '15 at 22:29
  • :) you are right. Nevertheless my answerer counts for the actor also. The project sponsor and the roles he/she is interested in should be story authors and/or at least actor. Including e.g. multiple stories on the same feature if new motivations / reasoning is introduced. – Tob Feb 22 '15 at 21:27
0

I found the question interesting because it's not one I'd thought of before; but your example is particularly interesting to me, because

As a user, I would like a way to turn off the stupid carousel, so that my web page stops flashing at me!

I usually think that the actor in a story should be the person who is trying to interact with the software; but this example really does seem to contain a feature that is primarily for the benefit of the site owner, rather than for the user.

The actor can be different for different stories; maybe the way to answer the question is "who benefits most from the story feature?"

0

I like to think of the actor as giving context to the story, such that it helps the team develop it correctly.

So my answer would be which ever of the versions of the story gives the most useful information.

In your example, do you want the team focusing on producing a carousel of products that makes the site owner happy? Or is it more important the the carousel of products is useful to the user? I suspect it is a mixture of the two, but that the effect on the end user is more important.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.