1

I'm trying to learn about Agile methodologies through the Head First Software Development book and after reading about it, I've tried to apply the concept of User Stories to a recent mini-project (set of new features added to an existing application).

Besides the fact that I have a hard time not thinking in terms of "tasks", I've also had trouble with the fact the client has asked things in a way that, to me, include implementation.

For example, instead of asking "we want Limited Users to have an Address now, just like Regular Users" and leaving the rest to us, they would say "we want Limited Users to appear in the same list as Regular Users and we want them to have an Address too, and it should be editable in the same Address Editing screen as Regular Users".

It seems to me that User Stories are meant to express a business need, but not its technical implementation, nor its UI implementation. That said, does it make sense that a client would impose its vision of the UI and have that be their business need?

How would I turn the client's request into one or more User Stories? Should I say "woah there! Tell me your ultimate goals and we'll see how we can get the UI to accomodate them later"? Should I make multiple stories, one for the main business need (Limited Users have an Address) and additional ones for the UI requests? Should I just make the business need a single story and have other concerns as details / acceptance tests?

Admittedly I'm quite wet behind the ears when it comes to Agile and User Stories and I have trouble defining how much goes into them and where the rest would go too.

| improve this question | |
  • 1
    Try not to capture implementation details in your stories. However, stories should have a notes section and that's where you would capture your customer's desires and try to accommodate them if you can. – Dunk Jul 29 '14 at 20:39
  • 1
    I don't see how the users are not involved in UI. That's what the "U" stands for. If not, most apps would still use a command line. – JeffO Jul 30 '14 at 2:20
  • Having read Software Requirements 3e since, I realize UI implementation details ("I want a combobox of users" instead of "I want to be able to pick a user") are really design Constraints. The book suggests always digging for the need behind the given solution. Sometimes it's simply random and should not prevent better solutions. Sometimes it's about training ease or a hidden need the UI element answers. – leokhorn Feb 3 '16 at 12:35
2

There's a finer line between requirement and implementation than what you're seeing. Reading over the example you provided, all I saw were requirements.

So let's break it down:

we want Limited Users to appear in the same list as Regular Users and we want them to have an Address too, and it should be editable in the same Address Editing screen as Regular Users

And we can extract the following requirements:

  • we want Limited Users [should] to appear in the same list as Regular Users

  • and we want them to [Limited Users should] have an Address too,

  • and it [The Limited User's address] should be editable in the same Address Editing screen as Regular Users

So with a little bit of editing we go from a perceived single requirement with implementation details to three separate requirements.

In the example, the client is giving you the leeway to figure out how to add in the actual implementation details. For example, if you need another table to store Limited User addresses, then use another table. If you want to re-use the same table as regular users, then go for it.

Now, whether you make one large user story or multiple stories will depend upon how big those tasks are and how long your sprints last. If you can complete all three requirements within a sprint, then handle it with one story. If it makes more sense to break it out into separate user stories, then do so. It really depends upon your team at that point.

| improve this answer | |
  • Are you saying that those 3 bullet points could all be stories? – dreza Jul 30 '14 at 1:37
  • @dreza - Depending upon their initial estimate / sizing, certainly. For example, the UI or its controller may require extensive work to be able to pull in an additional data source. But I'm not saying they have to be 3 separate stories. Team norms are going to dictate how many stories to create from those 3 requirements. – user53019 Jul 30 '14 at 13:56
  • I suppose part of me wonders how much say the client should have in the exact implementation of his needs. Sometimes it seems there would be other (better?) ways to do things than the tight canvas given. I suppose this might be part of The Discussion... and I might have to make another SE Question for that bit. – leokhorn Jul 30 '14 at 20:00
  • 1
    @leokhorn - that's where the fine line comes into play. The user may think they have a requirement to see XYZ in a particular way. If you can present a superior way of meeting that requirement they should be willing to accept it. – user53019 Jul 30 '14 at 20:42
2

The UI requirements should be part of the acceptance criteria of the story where that feature is implemented. You can -- and should -- negotiate and work together with the client about the UI before the story is labeled "ready" to be developed.

| improve this answer | |

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.