0

I've created a set of user stories. I have been asked to categorise them for the sprint e.g. header, footer, shop page etc.

However, it feels a little forced rather I have created user stories based upon the user needs as a website — as a whole. What do you think?

Also user goals I have categorised so far:

  1. business goals
  2. user goals
  3. design goals

Again, I have been asked to categorise further e.g. HR, Marketing, Sales etc — do you agree this is correct?

Some advice needed.

  • Tagging user stories with header, footer, shop page etc definitely doesn't make sense to me! – tobybot Apr 25 '18 at 21:48
  • 1
    Why do they want this extra categorization? What will it give them, or the user? What itch does it scratch for who? This sounds like a possible internal UX issue. For example I used to manage a website CMS and the science writers kept running out of content tags. But - it turns out they were just using tags as internal-facing "breadcrumbs" to facilitate their use of the CMS and pull content into different footholds in templates and pages. They'd never considered that tags were meant to be user-facing navigational meta data (or they wouldn't have had 600 of them and still be asking for more!) – Luke Smith Apr 26 '18 at 4:14
  • Maybe this is metadata for the developers to organize the stories around specific pieces of code, ie so they can grab whatever stories are tagged “footer” and tackle them together or something. I’m speculating. I think you should ask them what their motives are rather than all of us just wonder. Z – Luke Smith Jun 26 '18 at 3:33
1

This sounds like they're trying to catch user stories in components, and constrict those components in usage. That's not exactly what user stories are about. A user story is supposed to be a short statement about a task a user wants to do with a particular software. It briefly describes the user, the task, and what benefit the user gets from it.

However, in practice, this doesn't really happen often. There’s often business-driven or system-level requirements, which are not user-focused at all, that have to be crammed into the user story format. It’s easy to apply the user story format to everything, but this doesn't mean you should.

For example, what I often see is that inanimate things are used as subjects in stories. "As the system, I want to verify a user's identity with an OTP before granting access so that I can ensure secure connections". The problem is that this story personifies the system with wants and desires which it does not have. If it were truly a user story, the user would be the focus: "As a user, I want to log in safely so my account remains secure." Security and technology standards are not the primary concern of the user, so they aren't reflected.

Categorising stories into Sales or Marketing also doesn't make sense. Users don't care for that.

You can simply write tasks instead of stories. Write simple statements that declare what must be done. Call a user story that no longer involves a user what it actually is: a task for a developer to perform.

0

I think if you look at the way that you have created the user stories, they should also fall into natural groupings/categories based on the user's goals already, at least if you are writing them from a user-centric perspective. So based on those groupings, you may need to 'prepare' them in a way that the business analysts and developers are able to translate them into business and technical requirements (or maybe you are needing to fit the user requirements into them).

Typically users stories help to bridge the gap between the user's perspective to the existing business rules/requirements as well as the technical constraints, but business analysts and programmers don't see things from a user's point. Instead they normally align the documentations and specifications from the system's point of view, and that is possibly the purpose of the categorization exercise for you.

Without having the exact context, my advice is to consider the needs for the people who need this information and structure the user stories so that it fits into the way they are going to break down the work. Of course, you'll have your point of reference from the user's perspective, but you'll need a systematic way of mapping them back to business or technical requirements.

Given some of the categories you have mentioned, this sounds like an enterprise system and to me the categories reflect some of the users and use cases that form the main functionality of the system. So by all means try to work with the business analysts or developers to categorize and flesh out the user stories so that they can be reworked into functional specifications.

For example, fleshing out the user types and the functions they perform informs the developers of the access rights and permissions that may need to be implemented (according to business rules). Another example might be working out whether a particular feature to be implemented is core to the system (i.e. all users need to perform) or specific to a user type. These are all logical cateorization that can help developers to estimate the effort required and project managers to create a project timeline/schedule.

0

I think you need to provide more context for this project so the user groups you've mentioned will make more sense. I am guessing that HR, Marketing and Sales are different groups of users within your main user - the user of the system. Seems like this i a shopfront B2C type of system?

User stories in Agile are different from what we think of as "user stories" in the context of user experience design (UXD).A "user" in UXD is a persona within a scenario. The user in Agile is anybody who makes use of the system and defined by their roles whereas in UXD, users can be grouped by their goals, specific needs and contexts.

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.