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

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.

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.