5 ms·

Isn't this exactly the information that a User Story, as used in Agile, is supposed to capture?

tonyarkles 8y ago
Yes, that's what it's supposed to capture. In practice, what will sometimes (often?) happen is that someone will come up with a solution (e.g. elsewhere in this thread "The button on the right needs to be bigger") and then realize that it doesn't fit into the user story box. So they'll think about it for a second and write it as a user story: "As a user, I want the button on the right to be bigger"
- jiveturkey 8y ago
  yup. 9x out of 10 that’s what happens. personally i’m constantly pushing back on this type of story, or design doc requirement, even to principal level people.
  - tonyarkles 8y ago
    I think my favourite example was "As a user, I want the $COMPANY logo to be displayed prominently in the top-left corner of the application" Hell, I even accept that marketing is a valid stakeholder in the product. But just be honest about what it is! "For brand consistency, the marketing department would like the logo to be displayed in the top-left corner of the application, following standard company branding documentation." That's a perfectly fine "user" story (stakeholder story) I think. It answers the "why does the person want this?" question much better.
    - klenwell 8y ago
      This is a great example. But I still have a bone to pick with the edited user story. It's not really a user story and crosses the line into implementation. I'd propose a further revision: "As a user, I'd like the home page to reflect a consistent set of branding guidelines so it reinforces the company's identity for me." Logo display isn't covered by the branding guidelines? The company doesn't even have a branding guide? Now you've uncovered a deeper problem. Fix that and hopefully you'll avoid a lot of aimless subjective debates over cosmetic issues in the future.
      - tonyarkles 8y ago
        Generally speaking, as a user, I couldn't give a shit about the company's branding guidelines and how they display the logo, so long as it's not taking up 1/3 of the screen ;). But I get your point, and agree about digging into those aimless debates. "As a user, I'd like a consistent visual experience across $COMPANY's products"
  - anotheryou 8y ago
    How do you handle people that simply don't do well on this? I have for example a front-end guy who's not really good in UX and always jumps in to code instead of discussing a mockup first.
    - tonyarkles 8y ago
      I've been thinking about this a fair bit lately. How do you get from where you're at right now to something better? I haven't yet figured out any kind of holy grail approach that works, unfortunately :) What I have been thinking about quite a bit is the idea of "initial conditions" in software. If a project starts out in a super cowboy way (let's not think about requirements, bring on the code!) and proceeds relatively successfully that way for a while, it's damned hard to reign that back in to a process where you do requirements and think about the problem before starting to write code. Best I can tell, the way to keep things like this from getting out of hand is to nip them in the bud early before they become habits. That, unfortunately, doesn't help teams that are in the "nothing is thought out" swamp... Edit: I just remembered the Scott Adams article on HN today too, talking about systems. That's exactly what this is all about: making systems where it's just assumed that you're going to do the requirements work up front. You can still do this in an Agile way, you just don't immediately pluck a card off and start writing code; you normalize the fact that the person is going to spend some time thinking about the solution first and writing those thoughts down. That, too, is easier said than done. One team that I've worked with was heavily resistant to a 4 point checklist that was automatically added to their pull requests... It was not a burden and was specifically tailored to catching common mistakes they'd been making, but there was still a lot of resistance and ultimately the idea was abandoned.
      - anotheryou 8y ago
        Thank you for reply. I think it also depends a lot on the individual. You need more motivation to invest some thoughts instead of just getting it over with.
        tonyarkles 8y ago

Yes, that's what it's supposed to capture. In practice, what will sometimes (often?) happen is that someone will come up with a solution (e.g. elsewhere in this thread "The button on the right needs to be bigger") and then realize that it doesn't fit into the user story box. So they'll think about it for a second and write it as a user story: "As a user, I want the button on the right to be bigger"

jiveturkey 8y ago
yup. 9x out of 10 that’s what happens. personally i’m constantly pushing back on this type of story, or design doc requirement, even to principal level people.
- tonyarkles 8y ago
  I think my favourite example was "As a user, I want the $COMPANY logo to be displayed prominently in the top-left corner of the application" Hell, I even accept that marketing is a valid stakeholder in the product. But just be honest about what it is! "For brand consistency, the marketing department would like the logo to be displayed in the top-left corner of the application, following standard company branding documentation." That's a perfectly fine "user" story (stakeholder story) I think. It answers the "why does the person want this?" question much better.
  - klenwell 8y ago
    This is a great example. But I still have a bone to pick with the edited user story. It's not really a user story and crosses the line into implementation. I'd propose a further revision: "As a user, I'd like the home page to reflect a consistent set of branding guidelines so it reinforces the company's identity for me." Logo display isn't covered by the branding guidelines? The company doesn't even have a branding guide? Now you've uncovered a deeper problem. Fix that and hopefully you'll avoid a lot of aimless subjective debates over cosmetic issues in the future.
    - tonyarkles 8y ago
      Generally speaking, as a user, I couldn't give a shit about the company's branding guidelines and how they display the logo, so long as it's not taking up 1/3 of the screen ;). But I get your point, and agree about digging into those aimless debates. "As a user, I'd like a consistent visual experience across $COMPANY's products"
- anotheryou 8y ago
  How do you handle people that simply don't do well on this? I have for example a front-end guy who's not really good in UX and always jumps in to code instead of discussing a mockup first.
  - tonyarkles 8y ago
    I've been thinking about this a fair bit lately. How do you get from where you're at right now to something better? I haven't yet figured out any kind of holy grail approach that works, unfortunately :) What I have been thinking about quite a bit is the idea of "initial conditions" in software. If a project starts out in a super cowboy way (let's not think about requirements, bring on the code!) and proceeds relatively successfully that way for a while, it's damned hard to reign that back in to a process where you do requirements and think about the problem before starting to write code. Best I can tell, the way to keep things like this from getting out of hand is to nip them in the bud early before they become habits. That, unfortunately, doesn't help teams that are in the "nothing is thought out" swamp... Edit: I just remembered the Scott Adams article on HN today too, talking about systems. That's exactly what this is all about: making systems where it's just assumed that you're going to do the requirements work up front. You can still do this in an Agile way, you just don't immediately pluck a card off and start writing code; you normalize the fact that the person is going to spend some time thinking about the solution first and writing those thoughts down. That, too, is easier said than done. One team that I've worked with was heavily resistant to a 4 point checklist that was automatically added to their pull requests... It was not a burden and was specifically tailored to catching common mistakes they'd been making, but there was still a lot of resistance and ultimately the idea was abandoned.
    - anotheryou 8y ago
      Thank you for reply. I think it also depends a lot on the individual. You need more motivation to invest some thoughts instead of just getting it over with.
      - tonyarkles 8y ago