0

I sometimes find myself wondering if some of the user stories we are elaborating should just be implicitly implied. For example, if I had a user story of

As an administrator I wish to be able to edit a user so that I can change their details when required.

Is there a story implied by this such as

As an administrator I wish to be able to view all my users so that I can select one to edit

Due to the fact that in general you can't edit a user unless you can first find them to edit?

2

I think both your stories should be written better, in which case the problem vanishes:

As an administrator I want to change details of users so that (missing this)

and

As an administrator I want to browse users so that (missing this)

Not all sentences in the "As... I want... so that..." format are good or acceptable stories.

Using the stories I'm suggesting pre-empts your problem. If you are building user editing that's the goal you need to achieve -- whether you need a specific set of steps or another is a matter of negotiation, not a concern of the story.

If you need a user browsing feature, and you only know this if you know whether it has a value, then it should stand on its own.

More in general, good stories are INVEST and yours aren't:

  • they aren't Independent, as the first depends on the second
  • they aren't very Negotiable because they presume an implementation
  • they aren't Valuable in the way they are specified
| improve this answer | |
  • Thanks for the answer. I don't quite understand the "If you need a user browsing feature, and you only know this if you know whether it has a value" statement. Also I guess my story isn't written well. But surely there are some stories that are dependent such as you can't delete a user before adding, or browsing etc?? – dreza Jun 30 '14 at 20:22
  • Well, browsing users could have a value in itself, there could be some form of search or categorisation, etc. To answer you second point, one could certainly develop a user delete feature before a user add feature. I mean, there's no technical limitation. It doesn't happen because a delete story has no value if there are no users. This is not a dependency, but just a normal fact of life. In general terms, we expect values of stories to change with time and project advancement. – Sklivvz Jun 30 '14 at 20:33
  • Ok, I think I get that. As like you said browsing users could include searching, categorisation or anything, when estimating should you go into detail on what we are actually proposing to do then? I guess that was why my story was a bit more specific, to help with estimating. – dreza Jun 30 '14 at 21:15
2

TL;DR

As an administrator I wish to be able to edit a user so that I can change their details when required.

Your story is missing a meaningful value proposition. Specifically, your "I want" and "so that" section are largely duplicates of each other, and don't really explain the why of anything.

All stories contain organizational and team assumptions, are built on an organizational lexicon, and implicitly include the team's Definition of Done. These stories are placeholders for a larger conversation about a feature. However, getting the story right adds a lot of clarity and places some scope around that larger conversation.

A Worked Example

As an example, let's imagine that your current application doesn't let anyone but the database administrator (DBA) change user data. Currently, the application administrator is getting lots of support calls that have to be tossed over the wall to the DBA, because there's no interface in the application for changing a user's mailing address.

Your story now has some additional context that we might want to capture like so:

As the Foo Application Administrator
I want to be able to change a user's mailing address
so that support tickets can be closed without escalating to the database administrator.

With this story, we now have a concrete problem to solve, and the value proposition of the feature is much more clearly defined. This is progress!

Re-Working the Example

Then again, perhaps the real problem is that customers have to call in for support in the first place. Maybe the "feature" above is exposing the real problem. For example, consider this restatement of the original problem:

As a Foo Application User
I want to be able to change my own profile data
so that I don't have to call technical support to update my account.

Assuming that this is the root cause that was feeding the original story, this new story might provide even more bang for the buck. Remember, at the planning level it's important to look at the whole process, and not just the story in front of you.

Conclusion

Even if the examples above don't really apply to your specific example, hopefully they show how a more contextual and tightly-scoped story can be written. Agile practices rely on transparency and visibility, so it's very important to avoid "invisible work" while still ensuring that the stories are written at a level that communicates level-of-effort without dictating implementation details.

| improve this answer | |
  • Thanks! So in regards to your first story example. Would this implicitly imply that there needs to be some way for me to find the user in the first place in order to change their details. And hence, should a value story for that be written? – dreza Jun 30 '14 at 22:32
  • @dreza Please stop saying "implicitly imply." It's making my eyes bleed. --If something is clearly part of the level of effort, then it doesn't need it's own story. If you have to ask whether something is a separate feature or not, then you probably do need a separate story for it. It's just one of those things that depends on a team's agile maturity and technical skill level. – Todd A. Jacobs Jul 1 '14 at 0:14
  • lol ok fair enough. No more eye bleeding. I still don't understand how it's important to avoid "invisible work" however some work can be part of the level of effort but thanks for taking the time to answer. – dreza Jul 1 '14 at 1:26
  • 1
    @dreza, the point of discussion between the Product Owner and the team is precisely to make any "invisible work" visible and explicit. Once the team is aware of the whole set of tasks to be done in order to complete the story, they can decide whether to keep it as a single story or slice it up to multiple smaller stories (depending on its size, the sprint length, the team velocity etc.). – Péter Török Jul 1 '14 at 9:11
  • @PéterTörök Thanks, that makes sense. However I always thought the tasks were such things (if a web app): Create View, Create db layer etc I guess if they were Show list of users, Search for a user etc that might be different. – dreza Jul 1 '14 at 9:17
1

Well,I think both user stories are aiming for the same target (editing the user) but the acceptance tests for each one will definitely differ.

As in user story #1, you don't have to test the steps of selecting the user before editing and listing all the users functionalities; you'll just test the editing part while in user story #2 you'd need to test them to make sure that there is nothing wrong with the flow of the user story.

So I believe it depends on how you design the user stories general structure/theme (each user story explains only one functionality or multiple functionality?)

| improve this answer | |
  • Thanks Yassmeen. What would be the general best practice. One user story per functionality? – dreza Jun 30 '14 at 1:27
  • Hey Dreza,in my personal opinion I think the answer is Yes it should be one/functionality. Check the following link for more info about how to write a good user story. romanpichler.com/blog/10-tips-writing-good-user-stories – Yassmeen Jul 1 '14 at 14:17

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.