Project Management Stack Exchange is a question and answer site for project managers. It only takes a minute to sign up.
Sign up to join this community
I have two user account types: free and premium. Free users can upload one file per day. Premium users can upload unlimited numbers of files per day.
Is it correct to split user stories by user types, as in the examples below?
As a Free User I can upload 1 file per day.
As a Premium User I can upload unlimited files per day.
Having separate user stories for each type of user / persona is a valid approach however another approach could be to write/split stories based on expected/intended value. In your example, there could be one story:
As a user, I want to upload file(s) so that I can store my data on the server
and then this story can have 2 acceptance criteria:
- Free user can upload 1 file / day
- Premium user can upload unlimited number of files
Separate story for each persona would make more sense in case when each user expects a different value from the system, such as:
- As a contributor, I want to upload my article so that my work can be published
- As an editor, I want to review uploaded articles so that articles can be published
- As an admin, I want to remove articles so that I can maintain site's content policy
Is it correct to split user stories by user types?
Maybe. Maybe not. It really depends on your organizational context. There is no universally correct answer, but one suspects that in this case you are splitting user stories this way because you are treating stories as specifications rather than vertical slices of functionality.
It is often best to allow the development team some latitude in determining implementation details, and to avoid creating magic numbers and technical debt by over-constraining user stories. Obviously, this must be balanced against the YAGNI principle to guard against over-engineering, but allowing flexible design within a team's self-organizing process is generally a more agile approach than detailed specifications.
When you say how many uploads per day a given user may have, the easiest thing that could possibly work might be to hard-code an upload limit on some user records. One could argue that refinements could be done in future iterations, but one could also argue that this is unnecessary technical debt.
Truly iterative development doesn't ignore the design and architectural phases of product development. Rather, it encourages a just-in-time (or perhaps a "just enough") model where teams do sufficient planning to complete the features within the iteration with a minimum of technical debt.
The stories you have, as currently constituted, spell out how the feature is to be implemented, rather than describing a missing feature (e.g. the ability to define upload limits) or explaining how the feature adds value. This may be perfectly acceptable in some cases, but overuse of stories as specifications can inhibit agility.
User stories should definitely have a point of view, but the POV need not actually be the end user. For example, both of your stories may be addressed by a common story, such as:
As the marketing/sales director,
I want user upload limits to be set by some sort of permissions table
so that we can monetize our freemium model.
This story would probably get you to the same place as the stories in your original question, but has a different focus. The change in point of view provides the story more flexibility in its implementation (e.g. what if you wanted a third tier of bandwidth?), and provides a clearer statement of value and more context to guide the implementation details.
Note that this counterexample doesn't mean your original stories were "wrong." The point is that you should split stories up in any way that makes sense for the team and creates a deliverable unit of value. However, limiting stories to functional specifications often creates artificial constraints, so it may be useful to consider higher-level goals when deciding on how granular to make a given set of stories.
Yes.
If you want or need to split the story this is a good approach. Each part is complete/ independent and generates user value. There is probably a technical overlap which means the second story to be build will be easier. But there is no necessary order.
